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FOREWORD 


This  document  was  prepared  by  Computing  Devices  Company  and  Control  Data  Corporation 
under  the  joint  Navy/Air  Force  Aircraft  Armament  Interoperable  Interface  contract.  This 
document  is  being  published  and  distributed  as  a  technical  report  in  order  to  have  the  information 
it  contains  regarding  MIL-STD-1760  reach  as  many  users  as  quickly  as  possible. 

As  a  joint  service  contract,  many  people  and  organizations  were  involved  in  the  process  of 
providing  direction  and  review  that  led  to  the  completion  of  this  task  of  the  contract.  These 
organizations  and  personnel  included;  Naval  Weapons  Center  at  China  Lake  CA,  the  contracting 
office  for  the  contract,  and  Mr.  Carl  Stoddard,  the  contracting  officer  technical  representative 
(Code  3144);  the  Erigineering  Standardization  Division  of  the  US  Air  Force  (USAF)  Armament 
Division  (AD/ENSM)  at  Eglin  Air  Force  Base  FL;  the  Aircraft  and  Crew  Systems  Technology 
Directorate  at  the  Naval  Air  Development  Center  (Code  6012),  Warminster  PA;  Naval  Air 
Systems  Command  (AIR-540)  at  Washington,  DC;  ar'd  the  Systems  Engineering  Avionics  Facility 
of  the  USAF  Aeronautical  Systems  Division  (ASO/ENASF)  at  Wright- Patterson  Air  Force  Base  OH. 

This  document  compliments  a  previously  published  technical  report  written  by  LTV  Corp 
and  entitled  "Design  Principles  and  Practices  for  Implementation  of  MIL-STD-1760  in  Aircraft 
and  Stores"  (reference  number  ASD-TR-87-S028).  This  report  is  available  from  the  Defense 
Technical  Information  Center  or  the  National  Technical  Information  Service  ('•eference  number 
AD  At  83  724). 

The  views,  opinions,  and/or  findings  contained  in  this  report  are  those  of  the  contractors 
and  should  not  be  construed  as  an  official  Department  of  the  Air  Force  position,  policy  or  decision. 
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PREFACE 


This  document  is  the  Final  issue  cf  the  MIL-oTD-1760  Application  Guidelines  (CDRL  i.em  BOXC). 

This  work  has  been  undertaken  as  part  of  Phase  II.  Task  8  of  the  Aircraft  Armament  Interoperable 
Interface  (A2|2)  contract  (contract  number  N60530-82-R-0012).  The  contract  monitor  is 
Mr  Cart  Stoddard  of  Naval  Weapons  Center  (NWC),  China  Lake,  CA  and  the  technical  monitor  was 
Mr  John  SIK/inski,  and  then  Lt  Paul  Ivone  and  Mr  Richard  Lewandowski,  ASD/ENASF,  Wright- 
Patterson  Air  Force  Base,  OH. 

Principal  contributors  to  this  document  are: 

Computing  Devices  - 

Victor-^.  Fuller 
David  Fiough 
Steve  Knowles 
Hugh  Perry 
Rick  Wiles 
Brian  Winn 

WINTEC  - 

Frank  Woodall 

The  Computing  Devices  task  manager  is  Hugh  Perry. 

The  development  of  MIL-STD-1760  has  been  undertaken  with  the  objective  of  reducing 
significantly  the  proliferation  of  different  types  of  aircraft/store  electrical  interfaces,  thereby 
improving  aircraft/store  interoperability  and  reducing  store  integration  problems. 

This  document  addresses  those  issues  which  are  associated  with  the  practical  implementation  of 
MIL-STD-1760  in  a  real  aircraft  and  store  environment.  It  contains  the  results  implementation 
experience  gained  as  the  result  of  comprehensive  studies  and  the  full  implementation  and 
evaluation  of  the  standard.  This  experience  is  generalized  into  Application  Guidance  that  is 
considered  useful  for  assisting  future  implementors  of  the  standard. 

This  document  is  divided  into  three  parts: 

( 1  )  The  first  part  is  the  Application  Guidelines  Report  (AGR)  and  includes  program 
background  and  a  implementation  case  study. 

(  2  )  The  second  part  (Appendix  A)  is  an  issue  and  guidance  document.  It  includes  a 
summary  of  the  projected  benefits  of  the  standard,  a  brief  description  of  it  and  a  discussion 
of  the  MIL-STD-1760  Application  Process.  The  main  portion  of  this  second  part  contains  a 
list  of  implementation  issues  and  application  guidance  associated  with  each  issue. 

(3)  The  third  part  (Appendix  B)  contains  the  rationale  for  the  conclusions  contained  in  the 
second  part. 


Rob  Hill 
Peter  Hunt 
Peter  Mackean 
Sue  Spice 
John  Wilhelm 
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SECTION  1 


INTRODUCTION 


1.1  SCOPE  OF  THE  APPUCATIQN  GUIDEUNES  The  Appikiaten  Gkiideines  reoof^ 
gainud  and  lessons  learned  from  the  studkts.  designs  and  evaluations  undertaken  during  the  AAII 
Program,  and  provides  practical  guidance  and  associated  rationale  for  knplementors  of 
MIL-STD-1760  in  future  applications. 

12  PURPOSE  OF  THE  APPUCATIQN  GUIDEUNES  The  purpose  of  the  MIL-STD-1760  Application 
Guidelines  is  to  provide  practical  guidance  for  implementors  of  MIL-STD-1760  in  future  store 
and  aircraft  appH^tions,  as  Hkjstrated  in  Figure  1.1.  The  standard  has  a  significant  impact  on 
the  system  d^(^  of  related  avionics  systems,  such  as  the  Stores  Management  System  (SMS), 
analog  data  transfer  equipment,  the  P^ar  Ois^rftxjtion  System  (PDS)  and  Data  Transfer 
Equipment  (DTE).  It  also  impacts  the  desijp  of  the  stores  themselves.  It  is  anticipated  that  the 
document  wHI  provide  useful  information  to:  System  Program  Offices  (SPOs),  Aircraft  Prime 
Contractors,  Aviortics  and  Store  System  Designers.  System  Integrators,  and  Equipment  Users. 

The  document  has  been  developed  with  four  key  objec^es: 

a  To  identify  key  Implementation  Issues  relevant  to  the  MIL-STD-1760  Application 
process  and  provide  recommended  implementation  approaches  for  each  issue. 

b.  To  describe  the  practical  basis  and  rationale  for  recommendations  made. 

c.  To  provide  visibility  into  on-going  MIL-STO-1760  applications. 

d  To  allow  the  reader  lo  obtain  the  specific  information  he  needs  easily  and  rapidly. 
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FHGURE  1 .1  Purpose  arxi  Readership  of  the  Application  Guidelines 
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O  STRUCTURE  QF  DOCUMENT  The  document  is  divkied  into  ttvee  parts,  the  Application 
GuideCnes  Report  (AGR).  Appendix  A  entitled  'A  Guide  to  MIL>STO-1760  Applications, *  arxl 
Appendix  B.  The  AGR  summarizes  the  AAli  implementation  Examples  in  two  main  sectiorrs: 

a  The  AElSVaidation  System  (AVS)  and  AVS  Test  System 
b.  The  F-16  C/D  Aircraft  implementation  Case  StiK^ 

The  principal  content  of  Appendix  A  is  a  description  of  MIL-STD-1760  Implementation  Issues, 
and  recommended  guidance  for  the  implementation  of  each  one.  Appendix  B  includes  the  detaled 
rationale  for  the  implementation  guidance  included  in  Appendix  A. 


The  appicaton 


1.4  APPUCATIQN  GUIDELINES  DEVELOPMENT  PROCESS  AND  QVERAU-i 
guidance  contained  in  Appendix  A  has  been  derived  from  a  wide  eiqperienoe  base  of 
MIL*STD*1760  implementations.  Figure  1.2  illustrates  the  process  that  has  been  undertaken 
to  develop  the  issues  and  guidance  relevant  to  MIL-STD-1760  implementation.  The  list  of  issues 
has  been  derwed  from: 


a  System  studies  undertaken  in  Phase  I  of  the  AAll  Program  (Descrfoed  in  Section  4). 

b.  Detailed  system,  hardware  and  softvrare  experience  gained  through  the  design,  test  and 
evaluation  of  a  system  which  fuRy  implements  MiL-STD-1760  -  namely  the  AVS  (This  system 
is  described  in  Section  5). 

c.  The  P-16  C/D  Case  Study,  which  considered  design  issues  associated  with 
implementing  the  full  MIL-STO-17^  on  a  tactical  aircraft  utilizing  existing  avionics 
equipment  to  the  maximum  degree  practicable.  The  study  is  deserted  in  section  6. 

d  A  survey  of  Air  Force  planned  inq>tementatk>ns  of  MIL-STD>1760  in  aircraft  artd 
store  programs. 

Through  the  experience  gained  through  the  four  activities  descrt)ed  above,  implementation 
guidance  for  each  issue  has  been  dert^.  \Nher9  issues  have  been  considered  from  more  thar^  orte 
of  these  activities,  the  guidance  provided  is  an  amalgamation  of  the  results  of  each  activity.  This 
approach  has  enabled  a  wide  spectrum  of  experience  to  be  gairted  within  the  oortstraints  of  the 
program  schedule.  Figure  1.2  also  summarizes  the  main  sections  contained  in  the  AGR  »)d 
Appendbc  A.  Careful  oonsideratton  has  been  given  to  the  format  of  the  presentation  of  the 
Implementation  Guioance  in  Appendix  A.  Oependng  upon  the  particuiar  interest  of  the  reader,  he 
may  wish  to  reference  a  particular  topic  in  terms  of  the  relevant  MIL-STD>1760  paragraph, 
the  relevant  phase  of  the  Application  Process,  or  a  specific  implementation  issue.  Appendbc  A 
has  been  structured  to  sim^ify  the  reader's  access  to  his  relevant  data. 

1.5  CONTENT  QF  APPUCATtON  GUIDELINES  It  must  be  noted  that  material  was  not  gathered  after 
June  1986  for  the  AGR.  Consequently,  some  of  the  data  and  information  may  have  become 
outdated 
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APPENDIX  A 

VlNTRODUCfORY  'PARAGRAP’HS' 


O  PURPOSE.  GOALS  &  BENEFITS  OF 
MIL-STD-1760 

o  OVERVIEW  OF  MIL-STD-1760 

O  MIL-STD-1760  APPLICATION 
PROCESS 

o  IMPLEMENTATION  GUIDANCE: 

-  System  Definition 

-  System  Performance 

-  System  Design 

-  Equipment  Design 

-  Software  Design 

-  Equipment  Installation 

•  System  Integration,  In-Service 
Support 


FIGURE  1 .2  Guidelines  Development  Process  and  Overall  Document  Content 
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SECTION  2 


REFERENCED  DOCUMCENTS 


2.1  GOVERNMENT  DOCUMENTS  Unless  Otherwise  specified  in  paragraph  2.3,  the  following 
specificalions,  standards,  and  handbooks  form  a  part  of  this  document  to  the  extent  specified 
herein. 


2.1.1  Military  Standards 
MIL-STD-454 

MIL-STD-461 

MIL-STD-462 


Standard  General  Requirements  for  Electronic 
Equipment 

Electromagnetic  Interference  Characteristics 
Requirements  for  Equipment 

Electromagnetic  Interference  Characteristics, 
Measurement  of 


MIL-STD-704D 
MIL-Srr  ^  .2A 

Ml  «.u  I553e 

MIL-STD-1760 

MIL-STD-1815A 


Aircraft  Electrical  Power  Characteristics 

Safety  Program  for  System  and  Subsystems  and 
Equipment,  Requirements  for 

Aircraft  Internal  Time  Division  Command  Response 
Multiplex  Data  Bus 

Aircraft/Store  Electrical  Interconnection  System 
Ada  Programming  Language 


2.1.2  Military  Specifications 


MIL-E-5400  General  Equipmen'.  Er\'>oi  ..lent 

MIL-C-38999  Connecter.  '  c.rioal.  Circular,  Miniature.  High 

Density.  Quick  Disconnect  (Bayonet,  Threaded,  and 
Breech  Coupling),  Environment  Resistant,  Removable 
Crimp  and  Hermetic  Solder  Contacts,  General 
Specification  for 

2.1.3  Handbooks 

MIL-HDBK-244  Aircraft-''  re  Integration 

2.1.4  NATO  Standardization  Aorer  .-.am 


STANAG  3350  AVS  Monochrome  Video  Standard  for  Aircraft 

System  Applications 
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DRAFT  Aircraft/Store  Electrical  Interconnection 

MIL- STD- 1760 A  System  (Draft  for  Comment,  April  1985) 


DRAFT  Notice  1  to  Logical  Requirements  (June  1985) 
MIL-STD-1760A 


22  CONTT^ACTOR  DOCUMENTS 


CDRL:  COOK  -  Type  A  System  Specificalion  (for  an  AEIS  Implementation  System).  July 
1983  (Reference  COC  182-02-01). 


CDRL:  COOL  -  Generic  SMS  System  (Design  B1  Specification  (Reference  CDC 
182-04-02). 


182-51-02 

182-60-05 

182-60-06 

182-60-07 

182-60-08 

182-60-09 

182-60-10 

182-60-11 

182-60-12 

182-60-21 

182-70-07 

182-70-06 

182-70-13 

182-60-22 


AIM-9L  Parameters 
PCE  B2  Specifications  (CDC) 

SSE  B2  S^ifications  (CDC) 

SNE  B2  Specifications  (CDC) 

APS  B2  S^ifications  (CDC) 

CSE  B2  Specifications  (CDC) 

DC  B2  Specifications  (CDC) 

MFD  B2  Specifications  (CDC) 

SU  B2  Specifications  (CDC) 

Aircraft  Wiring  (CDC) 

MIL-STD-1760  Evaluation  Plan  (CDC) 
AVS  Evaluation  Plan  (CDC) 

LDD  Evaluation  Plan  (CDC) 
MIL-STD-1760  Impact  of  (Changes 


2.3  MIL-STD-1760  For  the  purposes  of  this  document,  MIL-STD-1760  shall  be  defined  as 
April  1985  draft  MIL-STD-1760A,  as  amended  by  June  1985  DRAFT  Notice  1  as  limited  by 
document  182-60-22. 
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SECTION  3 


DEFINITION  OF  TERMS 


3.1  DEFINITION  AND  USE  OF  TERMS  Terms  when  used  within  this  document  are  as  defined  in  the 
referenced  documents,  MIL-HDBK-244,  the  NATO  Glossary  of  Terms  and  Definitions  for 
Military  Use,  and  as  follows: 

3.1.1  AVS  -  This  is  the  AEIS  Validation  System,  as  described  in  section  5  of  this  document. 

3.1.2  AVS  Rk?  •  This  is  the  AVS  and  the  avionics  simulator  described  in  section  5  of  this 
document. 

3.1.3  AVS  Rky  System  -  This  is  the  total  evaluation  system  described  in  section  5  of  this 
document.  NOTE:  The  AVS  Rig  System  is  a  generic  SMS  simulator  and  It  contains  store 
simulation  systems.  Because  of  this,  stores  are  not  actually  released  or  jettisoned.  However,  for 
consistency  with  the  generic  SMS  requirements  the  terms  are  used  as  if  real  stores  were 
managed.  In  this  context  the  terms  should  be  t^en  to  mean  ‘functions  performed  as  if  the  AVS 
we'e  contained  within  an  In-Service  Aircraft.* 

3.1.4  Store  -  A  store  is  any  device  intended  for  internal  or  external  carriage  and  mounted  on  an 
aircraft,  whether  or  not  the  item  is  intended  to  be  separated  in  flight.  There  are  two  categories 
of  stores: 

a  Carriage  stores  are  suspension  and  release  equipment  that  are  mounted  on  a  non- 
permanent  basis,  and  may  be  fitted  to  more  than  one  aircraft  type  or  one  airaaft  station.  Pylons 
and  primary  racks  (such  as  MAU-12)  are  not  carriage  stores. 

b.  Mission  stores  are  all  stores,  excluding  caniage  stores  and  include,  but  are  not 
limited  to.  the  following: 

Missiles 

Bombs 

Nudear  weapons 

Rocket  pods,  dispensers  capable  of  ejecting  multiple 

submunitions,  guns  and  gun  pods 

Torpedoes 

Pyrotechnic  devices 
Sonobuoys 

Flares,  chaff  dispensers 
Drones 

Pods  (laser  designator,  electronic  countermeasures,  store 
control,  data  link,  reconnaissance) 

Fuel  and  spray  tanks 

Target  and  cargo  drop  containers. 

Note  that  pods  directly  associated  with  aircraft  flight  control  functions  are  not  considered  to  be 
stores.  Also,  note  that  individual  rockets,  gun  rounds  and  submunitions  are  not  considered  to  be 
stores.  In  general,  mission  stores  directly  support  a  specific  mission  of  an  aircraft. 
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3.1.5  Aircraft/Store  Electrical  Interconnection  System  (AEISI  -  The  AEIS  is  a  system  composed 
of  electrical  (and  fiber  optic)  interfaces  on  aircraft  and  stores  through  which  aircraft  energize, 
control,  and  employ  stores.  The  AEIS  consists  of  electrical  interfaces  necessary  for  the  transfer 
of  electrical  power  and  data  between  aircraft  and  stores  from  one  store  to  another  store  via  the 
aircraft.  It  is  defined  in  MIL-STD-1760. 

3.1.6  Electrical  Interface  Types  -  The  AEIS  consists  of  four  electrical  interface  types  as  follows: 

a  Aircraft  Station  Interface  fASh  -  The  Aircraft  Station  interface  is  on  the  aircraft 
structure  where  the  mission  or  carriage  is  electrically  connected.  This  interface  is  usually  on 
the  aircraft  side  of  an  aircraft-to-store  umbilical  cable  (Some  carriage  configurations  may  not 
use  an  "umbilical  cable,"  for  example  rail  launchers).  The  Aircraft  Station  Interface  locations 
include  pylons,  conformal  and  fuselage  hard  points,  internal  weapon  bays,  and  wing  tips. 

b.  Carriage  Store  Interface  fCSh  •  The  Carriage  Store  Interface  is  on  the  carriage  store 
structure  to  which  the  aircraft  is  electrically  connected.  This  interface  is  on  the  store  side  of  an 
aircraft-to-store  umbilical  cable. 

c.  Carriage  Store  Station  Interface  fCSSh  -  The  Carriage  Store  Station  Interface  is  on 
the  carriage  store  structure  to  which  ihe  mission  store  is  electrically  connected.  This  interface 
is  usually  on  the  carriage  store  side  of  the  carriage  store-to-mission  store  umbilical  cable 
(Some  carriage  stores,  such  as  rail  launchers,  may  not  use  an  umbilical  cable  but  use  some 
other  cable/connector  mechanism). 

d.  Mission  Store  Interface  tMSi)  -  The  Mission  Store  Interface  is  on  the  mission  store 
structure  to  which  the  aircraft  or  carriage  store  is  electrically  connected.  This  interface  is  on 
the  mission  store  side  of  an  aircraft-to-store  umbilical  cable,  a  carriage  store-to-mission 
store  umbilical  cable,  or  a  rail  launcher  cable/connector  mechanism. 

3.1.7  Standard  Store  Interface  (SSI)  •  The  term  "standard  store  interface*  is  used  to  describe 
any  electrical  aircraft/store  interface  which  complies  with  MIL-STD-1760. 

3.1.8  Non-Standard  Store  interface  (NSS11  -  The  term  "non-standard  store  interface"  is  used  to 
describe  any  electrical  aircraft/store  interface  which  does  not  comply  with  MIL'STD-1760. 

3.1 .9  Interoperable  Store  -  Any  store  with  an  SSI  that  is  intended  for  use  on  two  or  more 
aircraft  types  (excludes  special  carriage  trays). 

3.1.10  Aircraft  Station  -  The  term  "aircraft  station*  is  used  to  describe  a  primary  hard-point 
fixture  or  fixtures  on  the  aircraft  structure  at  which  a  number  of  primary  store  stations  and/or 
MIL-STD-1760  aircraft  station  interfaces  (ASI)  may  be  simultaneously  located. 

3.1 .1 1  Hierarchical  Bus  Network  -  Is  used  to  describe  a  network  of  two  or  more  MIL-STD- 
1553  buses  where  one  or  more  buses  has  a  command  response  protocol  independent  of  one  or 
more  of  the  buses,  and  which  have  data  passing  relationships. 

3.1.12  Arming  -  The  term  "arming"  is  used  *  describe  the  process  of  preparing  a  store  for 
employment  from  a  safe  condition.  Arming  is  only  initiated  as  a  result  of  positive  request  from 
the  aircrew  to  the  aircraft.  Arming  does  not  include  the  transition  to  an  irreversible  slate. 

3.1.13  trfeversible  Commit  -  This  term  is  used  to  describe  any  processes  which  result  in 
irreversible  changes  in  the  employment  states  of  stores  and  which  excludes  the  store  separation 
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process.  Subsequent  to  irreversible  commit,  either  a  clean  release  or  a  hang-fire  will  be 
achieved. 

3.1.14  Store  Separation  -  The  term  'store  separation*  is  used  to  describe  any  process  which 
results  in  the  intended  separation  of  stores  from  the  aircraft  while  In  flight.  The  process 
includes  bomb  release,  missile  launch,  rocket  fire  and  jettison  activities. 

3.1.15  Store  Employment  -  The  term  'store  employment'  Is  used  to  describe  the  process  which 
allows  a  store  to  fulfill  its  intended  operation  requirement. 

3.1.16  Firing  -  This  term  is  used  to  describe  the  process  of  causing  a  projectile  to  be  separated 
from  the  aircraft  through  a  tube  (It  Is  usually  applied  to  firing  guns,  rockets  and  dispenser  type 
munitions). 

3.1.17  Release  -  The  term  'release*  is  used  to  describe  the  separation  of  stores  from  the 
aircraft  in  flight,  usually  in  a  vertical  direction,  for  the  purposes  of  employing  the  store.  This 
would  include  'Eject  Launch.* 

3.1.18  Launch  •  The  term  'launch*  is  used  to  describe  the  process  of  separating  self-propelled 
stores,  such  as  missiles,  from  the  aircraft  in  flight  for  the  purposes  of  employing  the  store. 

3.1.19  Multi-function  controls  and  displays  (MFCD1  -  The  term  'MFCD*  is  used  to  describe 
those  cockpit  control  and  display  facilities  which  could  be  used  to  effect  store  control. 

3.1.20  Jettison  •  This  term  is  used  to  describe  the  process  by  which  stores  are  intentionally 
separated  from  the  aircraft  in  a  safe  and  unarmed  condition.  Jettison  is  normally  performed 
following  a  system  or  store  failure  or  when  the  safety  of  the  aircraft  may  be  in  jeopardy.  Stores 
may  be  selectively  jettisoned  individually  or  in  groups.  Emergency  jettison  separates  all 
appropriate  stores  from  the  aircraft  in  a  minimum  period  of  time. 

3.1.21  Reversionary  activity  -  The  term  'reversionary  activity*  is  used  to  describe  the 
process  which  may  occur  following  a  detected  system  or  store  failure,  which  attempts  to  allow 
system  availability  to  be  maintained. 

3.1.22  Store  selection  -  A  store  is  defined  as  having  been  selected  when  any  function  or  signal 
(other  than  store  communications  or  store  interruptive  BIT)  has  been  activated  or  applied  to 
that  store. 

3.1.23  Store  communication  -  The  term  'store  communication*  is  used  to  describe  transmission 
to/from  a  store  via  the  multiplex  data  bus. 

3.1.24  AEIS  Implementation  System  (AISI  -  The  term  "AIS*  is  used  to  describe  those  airaaft 
avionics  subsystems  which  are  directly  involved  in  the  implementation  of  the  AEiS.  The 
functional  boundary  of  the  ASI  is  not  necessarily  that  defined  by  the  physical  boundary  of  the 
avionics  subsystems  involved.  The  principal  subsystem  associated  with  the  AIS  is  the  SMS. 

3.2  ACRONYMS  AND  ABBREVIATIONS  These  are  defined  in  Appencfx  A. 
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SECTION  4 


OVERVIEW  OF  THE  CDC  AAII  PROGRAM 


4.1  THE  AIRCRAFT  ARMAMENT  INTEROPERABLE  INTERFACE  (AAII1  PRQGBAM_The  AAII  DfOQram 
is  a  ioint  US  Air  Force  and  Navy  program  which  has  been  tasked  to  develop  all  aspects  of  the 
Aircraft  Electrical  Interface  System  (AEIS),  as  defined  by  MIL-STD-1760.  The  program  is 
divided  into  a  number  of  elements,  as  shown  in  figure  4.1.  One  key  element  is  the  concept 
development  and  documentation  of  the  avionics  systems  which  will  implement  the  standard, 
together  with  the  design  of  the  logical,  or  protocol,  aspects  of  the  standard  itself. 

4.2  THE  CDC  AAII  PROGRAM 

4.2.1  Program  Ohineiivas.  The  following  discussion  describes  the  program  undertaken  by 
Control  Data  Corporation  (CDC)  and  its  then  subsidiary,  Computing  Devices.  UK.  The  work  was 
also  supported  by  WINTEC  Inc.  in  Valparaiso.  Florida,  and.  in  phase  I,  the  Boeing  Airplane 
Company,  Seattle.  Throughout  the  program,  which  covered  the  1982  to  1987  timeframe,  a 
number  of  changes  and  redirections  were  implemented  to  reflect  the  devetoping  status  of  the 
MIL-STD-1760.  After  the  first  one  year  phase  of  the  program,  the  CDC  contract  was  extended  to 
accommodate  the  MIL-STD-1760  program  requirements  of  both  the  Air  Force  and  Navy. 

The  major  objectives  of  the  program  were: 

a  To  determine  the  requirements  of  the  avionics  systems  which  will  be  required  to 
implement  MIL-STD-1760  on  future  USAF  aircraft  (The  principal  system  affected  is  the  Stores 
Management  System  (SMS)]. 

b.  To  develop  an  optimum  generic  system  architectural  design  which 
would  implement  these  requirements. 

c.  To  develop  a  Logical  Design  Definition  (LDD)  for  the  standard. 

d.  To  test  and  evaluate  MIL-STD-1760  within  a  fully  representative  system 
environment. 

e.  To  perform  a  MIL-STD-1760  implementation  case  study  on  an  in-service  aircraft, 
for  which  the  F-16  was  selected  and  to  survey  the  current  implementation  status  of  the  standard 
in  Air  Force  aircraft  and  stores  (These  studies  provide  real-world  implementation  experience). 

f.  To  document  all  the  MIL-STD-1760  Implementation  experience  gained  within  a  fully 
representative  system  environment,  in  an  Application  Guidelines  Report  to  assist  future 
implementors  of  the  standard. 
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FIGURE  4.1  The  Development  of  MIL-STD-1760 


4.2.2  Prinripal  Prooram  Tasks.  An  overview  of  the  tasks  undertaken  is  shown  in  figure  4.2. 
together  with  their  interrelationships.  The  program  was  (^vided  into  two  principal  phases,  and 
consisted  of  the  following  tasks: 

PHASEI 

( 1  )  Develop  AEIS  Implementation  System  (AIS)  Requirements 
(  2 )  Design  an  AEIS  LDD 
(  3 )  Develop  a  Generic  AIS  Design 

PHASE  II 

(  4 )  Design,  Fabricate  and  Test  an  AEIS  Validation  System  (AVS)  and  its  test 

environment. 

(  5 )  Test  and  Evaluate  MIL-STO-1760  and  the  AVS,  and  then  deliver  it  to  the 
Navy  1760  Test  Facility. 

(6)  Perform  a  MIL-STD-1760  Implementation  Case  Study  (on  the  F-16C/D). 
(  7)  Survey  the  planned  Air  Force  MIL-STD-1760  aircraft  and  store 
implementations. 

(8)  Develop  MIL-STD-1760  Application  Guidelines  to  assist  future 
implementors  of  the  standard. 

Tl)ese  tasks  are  shown  highlighted  in  figure  4.1  (where  relevant),  to  indicate  how  the  COC 
contract  forms  part  of  the  overall  MIL-STD-1760  development  program. 


FIGURE  4.2  Overview  of  CDC  AAII  Program 


4.2.3  Program  Schedule  The  AAII  program  schedule  (figure  4.3)  shows  the  duration  and 
completion  dates  of  each  of  the  principal  tasks  defined  in  paragraph  4.2.2. 
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FIGURE  4.3  COC  AAII  Program  Schedule 

4.3  TASK  DESCRIPTIONS  The  following  discussion  briefly  clescri}es  the  principal  tasks 
undertaken  during  the  AAII  program. 

4.3.1  DevfllQD  AIS  Reouirements  A  MIL-STD-490  Type  A  system  requirement  specification  was 
developed  to  dehne  the  system  functions  and  characteristics  of  the  AEIS  Implementation  System. 
This  system  is  required  to  control  both  existing  and  new  (MIL  STO-1760)  weapons  on  existing 
and  future  aircraft.  The  specification  was  developed  from  the  future  Air  Force  and  Navy  aircraft 
mission  requirements,  as  well  as  a  large  number  of  previous  related  studies,  relevant  standards 
and  spedfications.  The  specification  was  used  to  define  the  requirements  for  the  subsequent 
detailed  system  design  activities,  as  well  as  providing  an  input  to  defining  the  general  SMS 
requirements  for  the  Pave  Pillar  program.  Figure  4.4  shows  the  types  and  quantities  of  weapons 
that  will  be  carried  on  each  type  of  aircraft;  these  will  fulfill  the  foreseen  tactical  and  strat^ic 
missions  of  Air  Force  Aircraft.  The  figure  also  shows  the  quantities  of  MIL*STD-1760 
interfaces  that  will  be  needed  ’n  the  future,  and  as  such,  forms  a  prime  AIS  system  design  driver. 
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FIGURE  4.4  MIL-STD-1760  Weapon  Requirements  of  USAF  Aircraft  Types 
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4.3.2  Design  AEIS  Logical  Design  Definition  fLDDt  Figure  4.5  shows  the  three  elements  of 
MIL  STD-1760,  the  Physical.  Electrical  and  Ijogical  definitions.  The  development  of  the  LOD  by 
CDC  was  undertaken  to  comply  with  an  LDO  Type  A  specification,  and  the  system  requirements 
defined  in  the  AIS  Type  A  specification.  The  draft  LDD  comprised  of  the  major  elements  shown  in 
figure  4.6.  (The  LDD.  together  with  its  rationale  consisted  of  391  pages.)  M  has  si^>sequently 
undergone  revision  as  the  result  of  Government  and  Industry  review;  this  process  has  induded 
the  review  by  the  SAE  AE-9A  Task  Group. 

4.3.3  Develop  Generic  AIS  Design  The  task  of  developing  a  generic  AIS  design  consisted  of 
studying  alternative  system  architectures  which  would  implement  all  the  system  requirements, 
and  then  performing  trade-off  studies  to  determine  the  optimum  implementation  approach. 

Figure  4.7  illustrates  the  key  factors  that  influenced  the  system  design,  and  which  resulted  in  a 
Type  B1  specification  defining  the  central,  or  generic,  functions  of  an  AIS. 
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FIGURE  4,6  Page  Analysi,:  of  Proposed  AEIS  LDD 


^  DfiSian  Fabncatfl  and  Test  an  APIS.  Vafidatiun  System  (AVSI  and  its  Test  Enytronment  The 
AVS  arxJ  ns  teSi  environment  were  developed  to  provide  a  fuy  MIL-STD-1760  Imptementation 
environment  which  is  fully  representative  of  the  functional  LRU  partitioning  of  an  aifcraft 

systern.  An  overall  system  diagram  is  shown  in  figure  4.8.  a  detailed  descrtotion  of  the  system  is 
given  in  section  5. 
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FIGURE  4.7  Factors  Influerrcing  the  Generic  AIS  Design 


4.3.5  Test  and  Evaluate  MIL-STD-1760  and  the  AVS  The  first  part  of  this  activity  was 
concerned  with  testing  the  AVS  and  the  test  system  to  ensure  that  the  AVS  is  a  valid 
implementation  of  all  three  elements  of  the  standard.  It  also  verified  that  the  standard  is 
implementable  in  its  entirety,  and  that  it  contains  no  inconsistencies.  Issues  and  lessons  learned 
from  this  process  are  inciiK^  in  Appendix  A.  The  second  part  of  the  task  evaluated  the  standard 
and  the  way  in  which  the  AVS  implemented  it.  This  test  and  evaluation  (T&E)  process  produced  a 
large  number  of  1760  implementation  issues,  and  many  lessons  were  learnt  from  the  process. 
The  process  is  described  in  section  5  and  relevant  implementation  guidance  is  contained  in 
Appendix  A. 

4.3.6  Perform  F  I  6  Case  Study  An  in^ementation  case  study  was  conr^ed  on  an  aircraft 
representative  of  a  current  MIL-STO-1553  avionics  architecture.  The  F-16  C/D  was  selected 
as  being  a  stressing  case  in  terms  of  its  physical  and  performance  requirements,  and  the  wide 
range  of  new  weapons  it  will  carry  in  the  future.  The  main  purpose  of  the  study  was  to 
determine  implementation  issues  and  guidance  relating  to  incorporating  the  standard  on  an 
existing  aircraft,  while  making  the  maximum  use  of  the  exislir>g  weapon  management  system. 
The  study  is  described  in  detaH  Hi  section  6. 
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FIGURE  4.8  AEIS  Validation  System  and  Test  A  Evaluation  System 


4.3.7  Survey  ot  MIL-STD-176Q  Implementations  This  survey  identified  the  implemenlalion 
status  and  associated  issues  of  each  Air  Force  aircraft  and  store  program  currently  plani8ng  to 
implement  the  standard.  The  purpose  of  the  study  was  to  determine  the  implemerttaliort  factors 
which  these  programs  have  already  determined  through  their  experience,  and  to  enMtie  this 
experience  to  be  irKsrporated  mto  Appendix  A. 

4.3.8  PevelQO  ApoBcation  Guidelines  As  has  already  been  descitied  in  section  1.  the 
MiL-STD-1760  Application  Guidelines  documents  the  1760  implementation  experience  gained 
as  the  result  of  the  program.  While  desc^^  8ie  particular  activities  undertMren  (tai  ttte 
Application  Guidelines  Report).  Appendix  A  is  stnxmired  to  present  generM  1760 
implementation  issues  and  recommended  guidance  for  the  implementation  of  MIL-STD-1760  in 
future  aircraft  iNtd  store  programs.  The  appHcation  giMance  contained  in  Appendbt  A  addresses  a 
comprehensive  range  of  specific  mtplementation  issues.  These  have  been  dMem^ned  as  the 
result  the  wide  spectrum  of  design  experience  gMned  (Xxtog  this  program. 
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SECTION  5 


DESCRIPTION  OF  THE  AEIS  VALIDATION  SYSTEM  AND  THE  AVS  TEST  SYSTEM 

5.1  AEIS  VAUDATIQN  SYSTEM  (AVSl  This  section  provides  an  understanding  of  the 
requirements  and  design  of  the  AEIS  Validation  System  (AVS)  and  its  use.  Design 
guidance  gained  from  the  AVS  forms  a  substantiai  portion  of  the  guidelines  of  this 
document,  and  an  understanding  of  the  AVS  is  important  in  using  the  guidance  presented. 
Sections  5.1  through  5.3  address  those  three  subject  areas,  namely  the: 

a  AVS 

b.  AVS  Test  System 

c.  MIL-STD-1760  Test  and  Evaluation 

The  AVS  equipment  is  shown  in  figure  5.1 .  and  in  system  diagram  form  in  figure  5.2.  The 
overall  objective  of  the  AVS  was  to  ensure  that  a  valid  AEIS  standard  is  produ^.  The 
development  of  the  AVS  to  support  that  objective  is  described  below  for  the  following  phases: 

a  Objectives  (Para  5.t.l) 

b.  Definition  (Para  5.1.2) 

c.  Performance  (Para  5.1.3) 

d.  Interfaces  (Pira  5.1.4) 

e.  Design  (Para  5.1.5) 


FIGURE  5.1  AEIS  Validation  System  (AVS)  being  used  to  Test  and  Evaluate  MIL'STD-1760 


5.1.1  AVS  Objectives  The  overall  objective  for  the  AVS  as  stated  above  was  to  ensure  that  a  valid 
AEIS  standard  is  produced.  In  translating  this  objective  into  more  tangible  objectives,  it  was 
defined  that  the  AEIS  standard  would  have  two  main  components: 

a  MIL-STD-1760:  A  military  standard  which,  with  notices,  defines  physical, 
electrical  and  logical  interface  characteristics,  (refer  to  Appendix  A  sections  4  and  5). 

b.  Application  Guidelines:  Providing  further  interface  and  implementation  details 
which  can  be  used  or  mandated  on  specific  contracts. 

In  ensuring  a  valid  standard  the  AVS,  by  implementing  MIL-STD-1760,  would  support  both 
these  components.  MIL-STD-1760  evaluation  of  a  realistic  implementation  would  enable 
avoidance  of  incorrect  provisions  being  included  in  the  military  standard.  Application  Guidelines 
result  from  the  detailed  analysis  of  the  design  and  iniplementation  features  of  the  AVS.  The  AVS 
therefore  had  specific  objectives  of; 

a  Enabling  the  demonstration  and  evaluation  of  the  complete  MIL-STD-1760  including 
the  logical  elemoni 

b.  Enabling  the  demonstration  of  a  MIL-STO-1760  test  plan 

c.  Enabling  the  preparation  of  Application  Guidelines 

d.  Implementing  MIL-STD-1760  in  a  realistic  system  environment 

5.t.2  AVS  Definition  The  AVS  can  be  defined  principally  by  the  functions  it  executes.  The  main 
function  of  the  AVS  is  to  implement  MIL-STD-1760,  and  it  is  therefore  an  AEIS  Implenentation 
System  (AIS).  However,  as  with  all  AIS.  there  are  other  functions  that  the  implementation  will 
implement.  In  determining  the  functions  that  the  AVS  would  implement,  consideration  has  to  be 
given  to  three  main  factors: 

a  Costs  and  Timescales 

b.  AVS  objectives 

c.  Realistic  implemenu.tion 

The  functions  of  the  AVS  are,  therefore,  to  provide: 

a  MIL-STD-1760  AIS  Interfaces: 

Physical 

Electrical 

Logical 

b.  Existing  Store  Interfaces 

c.  Stores  Management  for: 

MIL-STD-1760  Air-to-AIr  Missile 
MIL-STD-1760  Alr-to-Ground  Missile 
MIL-STD-1760  Bomb 
MIL-STD-1760  Carriage  Store 
AMRAAM 

AIM-9L  Sidewinder 
MK  82  Bomb 

Suspension  and  Release  Equipment 


STORE  CODING  SIGNAL  CODING 


d  Data  Management: 

To/from  stores 
Data  Formatting 
Data  Computation  to  Store  Axes 
Interfaces  to  Stores  and  Aircraft 

e.  Stores  Management  Functions; 

Seiection 

Stores  State  Control  and  Monitor 

Targeting  Control 

Arming 

Release  Management 
Selective  Jettison 
Emergency  Management 
Inventory 
Weapon  BIT 

f.  Crew  Interfaces: 

Displays 
Critical  Controls 
Non-Critical  Controls 

g.  Miscellaneous; 

Aircraft  Wiring 
Pylon  Wiring 
Carriage  Wiring 

Full  details  of  the  AVS  functions  are  contained  in  the  references  defined  in  paragraph  2.2,  and 
particularly  in  the  AVS  Critical  Item  Development  Specification  182/51/01. 

5.1.3  AVS  Performance  A  full  definition  in  this  report  of  the  AVS  performance  would  be 
inappropriate.  The  AVS  specification  (reference  above)  contains  all  the  details.  The  ntost 
relevant  areas  of  the  specified  AVS  performance  are  listed  beiow. 

a  Loadouts  The  loadouts  for  the  AVS  are  shown  figuratively  in  figures  5.3  and  5.4.  The 
AVS  implements  five  pylon  stations  and  up  to  two  carriage  store  stations.  Each  station  has  a 
MIL-STD'1760  interface,  a  MK  82  Bomb  interface  and  an  S&RE  interface.  The  two  outboard 
stations  have  Sidewinder  interfaces  capable  of  full  SEAM  mode.  The  MIL'STD-1760  interface 
classes  implemented  are: 

( 1 )  Class  1A  ASI  for  three  central  pylons 

( 2 )  Class  1  ASI  for  outboard  pylons 

( 3 )  Class  2  CSSI  for  two  carriage  stations 

b.  Functional  Dependencies  The  input-output  dependencies  for  all  of  the  AVS  functions 
are  specified  as  for  a  real  AEIS  implementation. 

c.  Data  A  stressing  data  transfer  and  processing  performance  is  specified  for  the  AVS. 
Processing  tasks  include  conversion  between  MIL-STD-1760  and  non-standard  formats, 
computation  of  release  points,  and  conversion  of  target  data  between  aircraft  and  store  axes 
systems.  A  full  and  realistic  range  of  data  types  is  transferred  at  rates  and  precisions  of 
typically  25  Hz  and  16  or  32  bits,  respectively. 
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(AMRAAM) 


FIGURE  5.3  AVS  Store  loadouts  (MIL-STD-1760  Stores) 


21 


d  RfllBase/Jetlison  A  realistic  performance  is  specified  for  both  release  and  jettison. 
Key  points  include: 

( 1 )  Design  representative  of  single  fault  immune  and 
10'^/hour  hazard  rates. 

(  2 )  Release  packages  definable. 

( 3 )  Multiple  release  modes  with  release  spacings  selectable  to  1 0  meters 
minimum  spacing  at  variable  attack  velocities. 

( 4 )  Saparste  Selective  and  Emergency  Jettison  functions.  Both  are  sequenced  and 
Emergency  Jettison  is  single  fault  Immune. 

e.  Conirol/Dlsplav  A  multifunction  flexible  color  control  and  display  interface  is 
specified  for  the  majority  of  all  functions.  Critical  control  is  specified  by  inaividual  controls 
which  include  Master  Arm,  Trigger,  Ground  Test.  Selective  and  Emergency  Jettison  demands. 

f.  Inventory  A  stressing  self-determination  of  inventory  system  is  specified.  The  AVS 
does  not  have  an  inventory  panel,  thereby  reducing  the  represented  crew  loading. 

g.  Interfaces  All  Key  AVS  interfaces  are  realistic  in  connector,  signal  and  data  terms. 
(Refer  to  5.1.9  below.) 


h.  Built  In  Test  fBI'ri  a  multimode  BIT  implementation  is  specified.  BIT  coverage  is  a 
minimum  of  95%.  and  diagnosis  of  faults  to  individual  replaceable  units  Is  implemented. 


FIGURE  5.4  AVS  stores  loadouts  (existing  stores) 
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i .  Environment  A  ground  based  laboratory  environment  is  specified  to  reduce  cost. 


j .  Volume/Mass  To  reduce  cost  and  provide  increased  user  flexibility,  the  volume  and 
mass  of  the  AVS  are  not  constrained  to  flight  equipment  limits. 


5.1.4  AVS  Interfaces  The  AVS  implements  Interfaces  with  stores,  suspension  equipment  the 
aircraft  and  the  crew.  Key  points  are  listed  below. 

5.1 .4.1  Stores  Interfaces 

Connectors:  MIL-C-38999 

Signals:  MIL-STD-1760 

AIM-9L  interface 


5.1. 4 .2  Suspension  Equipment  Interfaces 

Connectors: 

Signals: 

5.1. 4.3  Aircraft  Interfaces 

Connectors: 

Signals: 


Multiple,  Circular 

As  MAU-12.  Modular  Rail  Launcher  (MRL) 


MIL-C-38999 

Triaxial  data  bus  connectors 

SMA  RF  connectors 

115  Volt  3  phase  power 

28  Volt  DC  power  (redundant  supply) 

MIL-STD-1553  Avionics  Data  Bus 

9  Analog  bidirectional  paths 


5.1 .4.4  Crew  Interfaces 

Multifunction  Display:  Multicolor 

Touch  Sensitive 
Multipaged 

Mixed  Store  Video/Symbol  displays 
Critical  Controls:  Discrete  Switches 

Momentary  Action  (Release.  Jettison) 

Two  state  (Master  Arm.  Ground  Test) 
Joystick:  4  way  control 

5.1 .5  AVS  Design  Three  areas  of  the  AVS  design  are  of  interest:  Functional  Partitioning 
(Philosophy  and  Implementation).  Internal  interfaces,  and  Key  Design  Features. 

5.1. 5.1  AVS  Functional  Partitioning  Philosophy  The  approaches  to  partitioning  in  the  AVS  are 
listed  below  for  the  main  external  and  internal  AVS  functions.  External  functions  are  concerned 
with  implementing  the  interfaces  which  are  external  to  the  AVS.  Internal  f  jnctions  are  those 
which  do  not  normally  directly  impact  external  interfaces. 

a  External  Functions 

( 1 )  Power  Switching  Medium  Power  (primary  interface)  switching  up  to  10 
Amps  is  distributed  to  remote  units  near  to  the  store  interfaces  to  minimize  aircraft  wiring  and 
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improve  EMC.  High  power  (auxiliary  interface)  switching  up  to  30  Amps  is  centralized  due  to 
the  high  volume  and  excessive  power  dissipation  associated  with  switching  these  currents. 

( 2  )  Critical  Switching  Critical  Switching  is  distributed  to  remote  units  near  to 
the  store  interfaces  and  suspension  equipment.  This  is  principally  to  reduce  the  EMC  hazards 
associated  with  long  wiring  lengths  of  critical  signals.  A  reduction  in  aircraft  wiring  also 
results. 


( 3 )  Analog  Network  The  Ai^atog  Network  is  centralized.  This  results  from  the 
need  to  keep  remote  units  small,  the  cost  of  Frequency  Division  Multiplex  (FDM)  systems,  the 
ability  to  use  high  bandwidth  wires  for  existing  store  signals,  and  the  reduction  in  aircraft 
wiring  that  centralized  networks  provide  for  most  airframes.  Figure  5.5  illustrates  this 
comparison.  The  analog  networking  is  located  separately  from  the  main  AVS  decision  processing 
to  allow  evaluation  of  an  AIS  architecture,  with  processing  integrated  into  a  mission  processing 
system. 


(  4 )  AEIS  Bus  Ck)ntrol  Centralized  and  located  with  AVS  decision  processing  to 
reduce  delays  n  stale  changes  and  data  transfer. 

(5)  Data  Formatting  Centralized  to  reduce  the  size  of  remote  units. 


(  6 )  Existing  Store  Interlaces  Complex  signals  are  centralized  to  reduce  the  size 
of  remote  units,  but  are  located  in  a  separate  unit  to  the  decision  processing  and  data  formatting. 
This  enables  evaluation  of  an  AIS  architecture  with  processing  integrated  into  a  mission 
processing  system.  Non-complex  generic  discrete  signals  are  distributed  to  remote  units  to 
reduce  aircraft  wiring. 


(  7 )  Avionics  Interface  Centralized  to  reduce  data  paths.  Data  bus  interface  and 
analog  interfaces  are  located  with  the  AVS  processing  and  analog  networks  respectively,  for 
similar  reasons. 


(  8 )  Di:.olavs/CQntrQls  Distributed  to  units  representative  of  cockpit  locatable 
equipments  and  panels. 

b.  Internal  Functions 

( 1 )  Decision  Processing  A  centralized  method  reduces  the  data  paths  and 
internal  bus  loadings  during  time-critical  functions,  such  as  multi-store  targeting  or  release. 

( 2 )  Built  in  Test  (BITt  BIT  mode  management  and  activation  are  centralized  to 
ensure  efficient  result  collation  and  overall  coordination  with  AVS  functions.  The  BIT 
functioning  within  the  remote  units  and  weapons  is  managed  by  remote  BIT  controllers  to  reduce 
the  central  processing  load  and  enhance  BIT  execution  times. 

(  3 )  DataBase  Centralized  for  efficient  access  by  the  AVS  decisbn  processing  and 
data  formatting. 

( 4  )  Internal  Interface  Management  Centralized  and  located  with  the  AVS  decision 
processing  to  provkie  rapid  control  and  monitor  of  AVS  state. 
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(  5 )  Power  Regulation  Distributed  to  units  where  regulated  power  is  consumed. 
This  results  in  lower  aircraft  wiring  than  would  centralized  or  part  centralized  power 
regulation. 


( 6 )  Power  Distribution  Centralized,  but  distributed  away  from  the  AVS  decision 
processing.  This  results  in  lower  aircraft  wiring  than  with  a  totally  distributed  system,  and 
also  allows  evaluation  of  an  AIS  architecture  where  decision  processing  is  integrated  into  a 
mission  processing  system. 

5. 1.5.2  AVS  functional  partitioning  implementation  The  AVS  is  shown  as  a  system  diagram  in 
figure  5.2.  The  AVS  comprises  the  following  functional  components: 

a  Process  Control  Equipment  (PCE) 

b.  Stores  Station  Equipments  (SSE) 

c.  Signal  Network  Equipment  (SNE) 
d  Auxiliary  Power  Equipment  (APS) 

e.  Carriage  Store  Equipment  (CSE) 

f.  Display  Controller  (DC) 

g.  Multi  Function  Display  (MFD) 

h.  Stubbing  Units  (SU) 

i .  Dedicated  AVS  Cockpit  Switches  (EJ.  PSJ.  TRIGGER.  MAS,  TEST  Joystick) 

j .  Armament  Bus 

k.  Aircraft  Wiring 

The  functions  of  these  components  are  described  below. 

a  PCE  Description  The  Process  Control  Equipment  (PCE)  is  the  main  system  controller 
of  the  AVS.  The  PCE  is  defined  in  specification  1 82-60-05.  It  executes  the  following  functions: 

( 1  )  Avionics  bus  interface 
(  2 )  Interfacing  with  critical  switches 

(3)  Armament  Bus  control  (MIL-STD*1553  bus) 

( 4 )  Armament  bus  discrete  control  with  single  fault  immune  EJ  function 
(  5 )  Store  state  control  and  monitor 

( 6 )  Store  data  supply  and  monitor 
(  7 )  AVS  LRU  state  control  and  monitor 
(  8 )  AVS  LRU  data  supply  and  monitor 

b.  SSE  Description  Each  Store  Station  Equipment  (SSE)  implements  the  discrete  and 
power  interfaces  for  one  pylon.  The  SSE  is  defined  in  specification  182-60-06.  It  executes  the 
following  functions: 

( 1  )  Provide  the  armament  bus  interface 
( 2 )  115  VAC  &  28V  DC  power  for  single  primary  ASI 
( 3  )  Release  consent  generation 
( 4  )  MAU-12  S&RE  control  and  monitor 

( 5 )  Fuzing  signals  generation 

(  6 )  LAU-127  S&RE  control  and  monitor 
(  7 )  Generic  discrete  input/output 

( 8 )  Single  fault  immune  EJ  function 

( 9 )  Provide  fault  isolation  lor  overcurrent  conditions 
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c.  SNE  Descfiptton  The  Signal  Network  Equipment  (SNE)  implements  the  high 
bandwidth,  low  bandwidth  and  existing  store  interfaces  for  the  AVS.  The  SNE  is  defined  in 
specification  l82*€0-07.  It  executes  the  following  functions: 


( 1  )  Armament  bus  interface 

( 2 )  Interface  to  HB1 .  H62.  HB3.  HB4  and  LB  for  five  ASIs. 

( 3 )  Interface  to  AIM-9L  guidance  and  audio  signals  multiplexed  onto  the  high 
bandwidth  signals  defined  above  for  two  ^Is. 

( 4 )  Provide  avionics  analog  interface  for: 

( a )  1x2  GHz  bidirectional  Interface 

( b )  4  X  20  MHz  at  50  Ohm  bidirectional  interface 

( c )  3  X  20  MHz  at  75  Ohm  bidirectional  interface 

(d)  lx  Low  Bandwidth  bidirectional  interface 

{ 5 )  Provide  analog  network  of  (ASI  nodes:  Aircraft  nodes: 

ASI-ASI  paths): 

(a)  5:1:0  2  GHz  network 

(b)  20:7:9  20  MHz  network 

( c )  5:1 :1  Low  Bandwidth  network 


( 6 )  Provide  AIM-9L  scan  function 

(  7 )  Provide  data  conversion  between  MIL-STD-1760  target  data  formats  and 
AIM-9L  guidance  formats. 


d.  APS  Description  The  Auxiliary  Power  Switch  (APS)  implements  the  power 
distribution  and  auxiliary  power  switching  of  the  AVS.  The  APS  is  defined  in  specification  182- 
60-08.  It  executes  the  following  functions: 

( 1  )  Armament  Bus  Interface 
(  2 )  Distribute  115  VAC  to  PCE,  SNE.  DC.  Pylons  1-5 

( 3 )  Distribute  28  VDC  A  &  B  to  PCE  and  Pylons  1  -  5 

( 4 )  Provide  switched  MIL-STD-1760  Auxiliary  Power  to  ASI  2,3  &  4 

(5)  Monitor  Power 

(  6  )  Provide  fault  isolation  for  overcurrent  conditions. 


e.  CSE  Description  The  Carriage  Store  Equipment  (CSE)  is  the  simulated 
implementation  of  the  electronics  of  a  MIL-STD-1760  twin  store  carrier  (or  multiple  ejector 
rack).  The  CSE  is  defined  in  specification  182-60-09.  It  executes  the  following  functions: 

( 1  )  CSI  Interface  to  MIL-STD-1760  ASI  (Primary  and  Auxiliary) 

( 2)  Provide  two  MIL-STD-1760  Class  II  CSSI  interfaces 

(  3 )  Control  and  monitor  for  two  MAU  12  S&RE 

( 4 )  Fuzing  signals  generation 

( 5 )  MIL-STD-1553  routing  between  CSI  and  CSSI 

( 6 )  High  bandwidth  arxl  Low  bandwidth  networking  between  CSI  and  CSSI 

(  7 )  P<mer  switching  and  fault  isolation  to  CSSI 

f.  DC  Descrtotion  The  Display  Controller  (DC)  Implements  the  interface  between  the 
cockpit  mounted  multifunction  display  (MFD)  and  the  avionto  bus.  The  DC  is  defined  in 
specification  182-60-10.  It  executes  the  following  functions. 


( 1  )  Avionics  Bus  Interface 
( 2 )  MFD  interface 
( 3  )  Joystick  interface 
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g.  MFD  Descfipiion  The  Multifunction  Display  (MFD)  implements  the  main  control  and 
monitor  interface  of  the  AVS.  The  MFD  is  defined  in  specification  182-60-11.  It  provides  the 
following  functions. 

( 1  )  RGB  driven  multicolor  cSspiay  surface  with  STANAG  3350  Class  B  video 

( 2 )  20  X  24  celt  touch  sensitive  surface  using  infrared  light  beams 

( 3 )  Interface  to  Display  Controller  (DC) 

h.  Stubbing  Units  Definition  Two  types  of  stubbing  units  are  used  in  the  AVS:  Avionics 
Stubbing  Units  (AvSU)  and  Armament  Bus  Stubbing  Units  (SU).  They  implement  the  stubbing 
functions  required  on  each  bus  to  reduce  tfte  aircraft  wiring.  The  stubbing  units  are  defined  in 
specification  182-60-12.  The  AvSU  is  required  to  implement  a  transformer  coupled  single  bus 
stub  to  MIL-STD-1553.  The  SU  provides  the  followving  functions: 


( 1  )  Tvro  transformer  coupled  single  bus  stubs 
( 2 )  Single  stubbing  of  EJ.  EJ*  and  SMS  Select  Signals 
( 3  )  Structure  Ground  Signals 

i .  Cockpit  Switches  The  AVS  implements  interfaces  to  five  external  switches  simulating 
cockpit  switch  functions.  These  switches  are  defined  as: 


(1)  Trigger  (TRIG) 

(2)  Pilot  Selective  Jettison  (SJ) 

(3)  Emergency  Jettison  (EJ) 

( 4  )  Master  Arm  (MAS) 

( 5 )  Ground  Test  (GND  TST) 

( 6 )  Joystick 


Ail  switches,  except  the  joystick,  are  designated  as  critical  switches,  and  they  interface  to  the 
PCE.  They  are,  except  the  joystick,  two  pole  double  throw  with  six  contacts.  The  joystick  is  a 
single  pole  four  way  switch  to  enable  movement  of  a  parameter  in  one  of  four  directiws. 

5. 1.5.3  AVS  Internal  Interfaces  The  key  details  of  AVS  internal  kiterfaces  relate  to  the  areas  of 
connectors,  power  interfaces,  (Sgital  interfaces,  discrete  signals  and  analog  sH^ials. 

a  Connectors  In  aooordance  with  USAF  policy,  good  design  and  high  EMCVEMP 
performance,  MIL-C-38999  connectors  are  used  for  an  AVS  unit  interface  with  3  exceptions: 


( 1 )  Triaxial  connectors  for  data  buses. 

(  2 )  SMA  connectors  for  2  GHz  signal  paths. 

( 3 )  High  Power  input  connectors  to  Auxiliary  Power  Switch  (APS). 

b.  Power  Interfaces  Power  interfaces  between  AVS  units  are  28  Volt  and  115  Volt  3 
phase  to  MlL-STO-704  voltages. 
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c.  Dk;iital  Intarfacas  MIL-STD-1553  is  used  as  the  transfer  mechanism  for  most  AVS 
internal  data.  Other  candklate  systems  such  as  non-standard  serial  data  bus.  High  Speed  Data  Bus 
(HSDB)  or  Pi  Bus  were  rejected  on  the  basis  of  either  lack  of  applicability  to  future 
implementations,  or  lack  of  current  support  equipment. 

Communication  tetween  the  PCE  artd  the  Display  System  is  consolidated  with  the  avionics  data 
bus.  and  aH  other  inter-unit  communication  is  consolidated  with  the  amnament  data  bus.  This 
reduces  hardware,  software  and  aircraft  wiring. 

Data  Bus  protocols  are  determined  by  the  other  users  of  the  buses  (that  is  the  Avionics  artd  the 
Armaments  systems). 

Data  transferred  internally  includes  control,  monitor,  target  position,  system  time  and  BIT 
information. 

d.  Discrete  Signals  The  use  of  discrete  signals  internal  to  the  AVS  is  minimized  to 
reduce  aircraft  wiring  and  to  support  the  use  of  standard  data  bus  interfaces.  Some  data  elements 
are  selected  to  be  transferred  as  discrete  signals  for  reasons  of  either  reduced  complexity  or 
safety.  Examples  include: 

( 1 )  SMS  selects  (Safety-Critical  Enable) 

( 2 )  Emergency  jettison  demand 

a  Analog  Signals  No  analog  signals  are  transferred  between  AVS  units  in  nomial  use. 
Analog  signals  are  transferred  between  the  external  interfaces  and  the  analog  netwoik.  The  AVS 
can  be  configured  to  display  weapon  targeting  video  on  to  the  display  system. 

5.1 .5.4  AVS  Key  Design  Features  Full  detail  of  key  AVS  design  features  is  included  in  Appen(£x  A 
with  its  supporting  rationale.  The  key  features  of  the  AVS  design  (as  opposed  to  specification), 
not  descrbed  above  are: 

a  Software  designed  and  written  in  Ada  (MIL  STD-1815). 

b.  Highly  generic  software  architecture  with  reusable  packages,  automatic  loadout 
identification  and  configuration  of  data  processing. 

c.  Back-up  hardware  guard  systems  to  prevent  critical  hazards  due  to  software 
failures. 

d  Mixed  technology  safety-critical  switching. 

e.  MIL-STO-1760  signal  lines  utilized  for  existing  store  interfaces. 

f.  MIL-STD-1760  protocols  and  formats  used  for  internal  control  and  monitor. 

g.  MIL-STD-1553  interface  designs  optimized  for  MIL-STD-1760  protocols. 
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5.1. 5.5  PCE  FunctionaJ  Design  Refer  to  figure  5.6  PCE  Block  Diagram,  while  reading  this 
paragraph.  The  Avionics  RT  board  provides  a  dedicated  MIL-STD-tSSS-to-shared  memory  and 
shared  memory-to-MIL-STD-l553  interface  to  the  aircraft  Avionics  bus.  The  Avionics 
processor  provides  the  interpretation  and  reformatting  of  the  avionics  data  which  is 
communicated  via  shared  memory  to  and  from  the  SMS  processor.  The  avionics  data  irciudes 
targeting  information  and  MFD  selection  data.  The  SMS  processor  provides  the  formatting  of 
stores  management  data  into  LDD  format  for  1760  store  control  and  appropriate  formats  for 
existing  stores  control.  The  MtL-STD-1553  message  data  is  passed  via  shared  ntemnry  to  the 
Armaments  Bus  Bus  Controller.  This  contains  a  68000  microprocessor  which  ensures  correa 
sequencing  of  message  transfers  on  the  armaments  bus.  For  safety  critical  message  transfers  the 
appropriate  safety  critical  codes  are  accessed  from  the  EJ  controller  board.  The  safety  critical 
codes  are  hardware  interlocked  to  the  appropriate  cockpit  switches  to  enhance  system  ^ety. 

The  EJ  controller  board  provides  single  fault  immune  Emergency  Jettison  function.  SMS  relay 
drives  and  the  cockpit  switches  interface.  The  128Kx16  battery  backed  up  RAM  is  provided  for 
program  and  data  memory  use  by  the  SMS  processor,  the  Avionics  processor  and  the  Bus 
Controller  processor.  The  VME  Arbiter  is  the  VME  bus  management  controller  which  prioritizes 
VME  bus  accesses  for  the  three  processors  in  the  PCE. 


Figure  5.6  PCE  Block  Diagram 


5. 1.5.6  SSE  Functional  Design  Refer  to  figure  5.7,  SSE  Block  Diagram,  while  reading  this 
paragraph.  The  General  Purpose  RT  PCB  provides  the  MIL-STD-1553  armaments  bus  interface 
to  the  dedicated  hardware  latches  and  monitors  of  the  SSE  circuitry.  A  modulo  2  with  shift  left, 
checksum  check  is  carried  out  on  all  incoming  messages  and  coded  up  on  ail  outgoing  messages. 
The  safety  critical  output  information  contained  in  subaddress  1 1  messages,  words  3  and  4  is 
passed  to  the  Safety  Criticai  Checker  PCB.  where  code,  sequence  and  parity  checks  are 
performed.  If  the  checks  are  successful  the  1760  store  state  descriptors  are  latched  into  the 
Safety  Critical  Driver  PCB.  The  Safety  Critical  Checker  PCB  also  provides  the  28V  discrete 
input  interface  f'-om  the  S  &  RE  connectors.  The  Safety  Critical  Driver  PCB  provides  dual 
channel  drives  for  the  safety  critical  outputs,  as  welt  as  single  channel  arives  for  the  power 
output  switches.  Single  fault  immune  EJ  is  ensured  by  the  use  of  discrete  EJ  inputs  as  well  as 
MIL-STD-1553  initiated  EJ.  A  Ov  discrete  input  monitor  interface  is  provided  from  the  S  &  RE 
connectors.  The  Relay  and  FET  modules  contain  the  output  switches  for  the  safety  critical  and 
power  outputs.  The  Switch  Monitor  PCB  provides  passive  monitors  for  all  stages  of  the  safety 
critical  output  path  to  ensure  maximum  fault  isolation.  The  interpretation  of  the  P'^'nitors  is 
carried  out  by  the  S-SE  Processor  PCB  which  is  outside  the  safety  critical  path  for  isons  of 
safety,  but  which  does  have  a  veto  to  disable  all  safety  critical  outputs  in  the  event  of  an  unsafe 
condition  occurring.  EJ  is  still  pos^  )le  via  the  discrete  EJ  inputs  however  ana  cannot  be 
disabled  by  the  processor.  The  processor  has  the  ability  to  fully  exercise  the  safety  critical  path 
during  IBIT,  but  hardware  interlot^s  are  provided  to  ensure  that  unsafe  conditions  cannot  occur. 
The  processor  PCB  also  provides  the  28v  and  Ov  discrete  output  drives.  The  PSD  module 
provides  dual  channel  supplies  for  the  EJ  function  to  ensure  single  fault  immunity  to  a  single 
supply  loss. 
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Figure  5.7  SSE  Block  Diagram 
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5. 1.5.7  SNE  Functional  Design  Refer  to  figure  5.8  SNE  BLOCK  DIAGRAM,  while  reading  this 
paragraph.  The  Remote  Terminal  PCB  provides  a  dedicated  MIL-STD-1553  to  shared  memory 
and  shared  memory  to  MIL-STD-1553  interface  to  the  aircraft  armaments  bus.  The  SNE 
processor  provides  the  interpretation  and  reformatting  of  the  data  including  system  time, 
targeting  data  and  network  control.  Sidewinder  control,  including  full  SEAM  mode 
implementation  is  provided  by  the  Sidewinder  PCB  controlled  via  the  processor  for  ASIs  1  and  5. 
The  four  Network  PCBs  and  RF  module  provide  for  full  Class  I  1 760  networking  on  all  ASIs  and 
the  Aircraft  Interface.  Networking  of  sidewinder  signals  fcr  ASis  1  and  5  is  handled  using  HB1. 
HB2,  HB4  and  LB  signals. 


Figure  5.8  SNE  Block  Diagram 
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5.1. 5.8  APS  Functional  Design  Refer  to  figure  5.3  APS  BLOCK  DIAGRAM,  while  reading  this 
paragraph.  The  APS  RT  provides  a  dedicated  interface  to  the  MIL-STD-1553  armament  bus. 
Each  incoming  message  is  verified  using  a  n^odulo  2  with  shift  left  checksum  check,  before  being 
latched  into  dedicated  circuitry  on  the  Driver  Monitor  PCBs.  All  outgoing  monitor  messages  have 
a  modulo  2  with  shift  left  checksum  coded  into  them  before  transmission.  The  Chvor  Mor..or 
PCBs  provide  relay  drives  for  the  Auxiliary  output  power  relays  for  ASIs  2.  C  and  4  as  v^c‘l  as 
monitors  of  APS  supplies  for  fault  determination.  This  information  is  inte  ,  ia  the  PCE 
since  no  processing  intelligence  exists  within  the  APS.  Circuit  breakers  arc.  pro  riue<J  on  the 
Auxiliary  outputs  to  provide  overcurrent  protection  under  fault  conditions  at  the  ASI.  The  APS 
provides  power  distribution  to  other  AVS  units,  which  is  separately  fused,  to  enable  degraded 
system  performance  in  the  case  of  one  or  more  units  developing  an  overcurrcnt  fault. 
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Figure  5.9  APS  Block  Diagram 
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5.1 .5.9  CSE  Functional  Design  Refer  to  figure  5.10  CSE  BLOCK  DIAGRAM,  while  reading  this 
paragraph.  The  CSE  contains  the  following  boards  which  perform  identical  functions  to  those  in 
the  SSE  except  that  they  control  two  CSSIs.  (Further  information  in  5.1. 5.6).  RT  PCB,  Safety 
Critical  Checker,  Safety  Critical  Driver,  Relay  and  FET  Modules  and  Switch  Monitor  RGBs. 
Additionally  they  perform  Auxiliary  Power  switching.  The  Dual  Pori  Ram  PCB  is  the  1553 
mecsage  store  into  which  all  MIL-STD-1553  messages  received  are  placed.  The  Processor  PCB 
reformats  the  appropriate  messages  to  the  CSSIs  and  receives  messages  from  the  CSSIs  to  be 
passed  back  to  the  Armaments  bus  RT  via  the  Dual  Port  Ram.  The  Processor  PCB  also  carries  out 
BIT  checks  on  the  majority  of  the  hardware  to  provide  maximum  fault  isolation  capability.  The 
Bus  Controller  PCB  controls  transactions  on  the  CSSI  MIL-STD-1553  bus  under  the  control  of 
the  Processor  as  described  above.  The  CSSI,  Bus  and  Misc.  PCB  contains  the  CSSI  bus  and  stub 
components  including  MIL-STD-1553  drivers  and  transformers.  It  also  provides  switching  for 
a  Class  I1 1760  Analog  interface  to  the  two  CSSIs  X  and  Y. 
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Figure  5.10  Carriage  Store  Equipment  Block  Diagram 
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5.1.5.10  DC  Functional  Design  Refer  to  figure  5.11  DC  Block  Diagram,  while  reading  this 
paragraph.  The  MIL-STO-1553  RT  PCB  provides  the  interface  to  the  aircraft  avionics  bus. 
Screen  display  information  and  handshaking  is  provided  via  the  MIL-STD-1553  avionics  bus  and 
passed  to  the  Control  Processor.  The  Control  Processor  interprets  the  information  and  formats 
appropriate  graphics  commands  which  are  passed  to  the  ANGUS  PCB.  The  Control  Processor  also 
interprets  the  touch  sensitive  infrared  switch  presses  for  transmission  via  the  avionics  bus  to 
the  PCE.  The  ANGUS  PCB  is  a  high  level  graphics  control  processor  which  interfaces  to  the  48K 
byte  Video  Store  Controller,  which  contains  the  pixel  display  information.  The  Address  Output 
Generator  PCB  controls  the  outputting  of  video  information  from  the  video  ram  to  the  Video 
Output  PCB.  The  Video  Output  PCB  contains  the  color  palette,  gray  scale  generator,  RGB  output 
DACs  and  external  video  input  mixing  circuitry.  The  RGB  output  is  used  to  drive  the  MFD 
directly. 
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Fig  5.11  Display  Controller  Block  Diagram 
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5.1.5.11  MFD  Functional  Design  Refer  to  figure  5.12  MFD  Block  Diagram,  while  reading  this 
paragraph.  The  MFD  provides  the  appropriate  drcuit.y  required  to  take  an  external  RGB  input 
with  sync  on  green  and  provide  all  drive  signals  to  control  the  color  CRT.  Tho  Infrared  Overlay 
and  Control  Electronics  are  self  strobing  but  interrogation  control  and  response  is  provided  via 
the  Display  Controller. 


IH  Overway 
*  Electronics 


Figure  5.12  MFD  Block  Diagram 

5.1.5.12  SU  Functional  Design  There  are  two  types  of  Stubbing  Units,  the  Avionics  SU  and  the 
Armaments  SU.  The  Avionics  SU  provides  for  a  continuation  of  the  avionics  bus  with  a  single, 
transformer  coupled  stub  being  provided  to  the  equipment  in  question.  The  Amnaments  SU 
provides  for  a  ccitinuation  of  the  armaments  bus  with  two,  transformer  coupled  stubs  being 
provided  to  the  equipments  in  question.  The  Armaments  SU  also  provides  for  the  busing  of  the 
discrete  signals  EJ,  4:J.  and  SMS  SELECT,  with  a  single  stub-off  of  each  of  these  signals  to  the 
equipment  concerned.  In  each  case  two  stubbing  units  are  required  at  each  RT  station  to  provide 
A  and  B  channel  MIL-STD-1553  buses. 

5.2  AVS  Test  System 

5.2.1  General  The  AVS  Tost  System  1$  shown  in  figure  5.13.  The  Test  System  supports 
achievement  of  the  overall  AVS  objectives  by  enabling  the  AVS  to  be  used.  This  requires 
simulaiion  of  all  the  equipments  and  functions  that  are  external  to  the  AVS  and  which  are 
interactively  managed  by  the  AVS. 
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5.2.1 .1  A  VS  Test  System  Overview  The  AVS  Test  System  (AVSTS)  comprises  of  an  Avionic 
Simulator  and  Control  Unit  (ASCU)  and  a  Store  Simulator  and  Monitor  Unit  (SSMU).  The  AVSTS 
interfaces  to  the  AVS  as  shown  in  figure  5.1.  and  has  the  functions  as  shown  in  figure  5.13 
(AVSTS  Block  Diagram).  The  ASCU  consists  of  two  processors,  which  have  the  following 
functions: 

a  Processor  A  •  provides  the  avionics  simulation,  target  simulation  and  interface  to  the 
operator. 

b.  Processor  B  •  provides  the  communications  between  processors  A  and  the  SSMU. 

Avionics  and  targeting  information  is  provided  via  the  Bus  Controller  Unit,  which  acts  as  the  Bus 
Controller  on  the  MIL-STO-1553  Avionics  Bus.  interfacing  to  the  AVS.  EJ  and  SMS  Select 
discretes  are  also  provided  by  the  AVS  to  the  ASCU.  Processor  A  interfaces  also  via  an  RS232 
link,  to  a  control  and  monitor  VOU,  which  enables  the  operator  to  control  set  up  of  the  AVS  and 
monitor  the  state  of  the  AVS  during  operation.  Information  is  passed  between  processors  in  the 
ASCU  via  common  RAM  and  an  inter  processor  link.  This  information  is  targeting  information 
for  communicating  to  the  SSMU.  Both  processors  are  able  to  interface  to  displays  which  show  the 
states  of  system  time,  discretes  and  Store  (SSMU).  The  SSMU  interfaces  to  the  ASCU  via  an 
RS232  interface,  and  the  information  passed  over  this  link  is  targeting  and  SSMU  status 
(control/monitor).  The  SSMU  communicates  with  the  AVS  via  the  MIL-STD-1S53  Armament 
Bus.  To  enable  this  the  SSMU  has  a  remote  terminal  unit  which  provides  dedicated  links  between 
1 553  and  shared  memory  and  between  shared  men.ory  and  1 553.  Also  interfaced  between  the 
SSMU  and  the  AVS  are  the  following  1760  signals:  1760  Discretes,  1760  LBW.  and  1760  HBW, 
which  are  used  to  set  the  state  of  the  stores.  There  is  also  an  S  &  RE  interface  between  the  SSMU 
and  the  AVS  for  provision  of  the  necessary  signals  for  jettisoning  or  firing  of  stores. 

5.2.2  AVS  Test  System  Huncttons  The  AVS  Test  System  provides  both  simulation  and  monitor 
functions.  The  AVS  Test  System  does  not  provide  worst  case  signal  loads  or  full  signal  monitoring 
capability,  where  these  can  be  provided  by  simple  external  loads.  Functions  of  the  Test  System 
are  detailed  below: 

a  Simulation  Functions 

Avionics  Bus  Control 

Avionics  Data  Source  (MIL-STD-1553) 

Weapons  State  Simulation 
Weapons  Data  Source 
Suspension  Equipment  Simulation 
Fault  Simulation 

b.  MoniiQf  Functions 

AVS  State  of  Health 
Avionics  Data  Values 
Weapons  Data  Values 
AVS  Error  Defection 
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Figure  5.13  AVSTS  Block  Diagram 
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5.2.3  AVS  Test  System  Design  As  shown  in  figure  5.6,  the  AVS  Test  System  has  two  unit  types. 
These  are  an  Avionics  Simulator  and  Control  Unit  (ASCU)  and  a  Stores  Simulator  and  Monitor 
Unit  (SSMU).  Although  only  one  ASCU  and  one  SSMU  are  detiveiabie  items,  up  to  two  SSMU  were 
used  in  the  test  and  evaluation  of  the  AVS.  Functions  of  the  ASCU  and  SSMU  are  detailed  below: 

a  ASCU  Functions 

Avionics  Bus  Control 
Avionics  Data  Source  and  Monitor 

AVS  Test  System  Controller  and  Display  (via  additional  VDU) 

Armament  Bus  Monitor  (with  additional  equipment) 

AVS  State  of  Health  Monitor 

b.  SSMU  Functions 

Weapons  Simulation: 

MIL-STO-1760  Air-to-Air  Missile 
MiL-STO-1760  Air  tO'Ground  Missile 
MIL-STD-1760  Bomb 
AMRAAM 

Sidewinder  AIM-9L 

Weapon  Data  Source: 

MIL-STO-1553 

Video  (STANAQ  3350  Class  B) 

Lew  Bandwidth 
Interlock  Signals 
AIM-9L  Audio 
AIM-9L  Guidance  Signals 

Suspension  Equipment  Simulation: 

MAU-12 

Modular  Rail  Launcher 
Store  on  Station  signals 
Rack  Unlock  and  BIT  signals 

Data  Monitor  and  Display: 

Weapon  State 
Target  Data 
Errors  Detected 
System  Time 

Signal  Monitor  and  Display: 

Release  Sigrials 
Arming  Signals 
Power  Supplies 
Interlock  Signals 

5.3  MIL-STD-1760  Test  and  Evaluation  The  overall  objective  of  the  AVS  was  to  ensure  a  valid 
AEIS  standard.  To  achieve  that  objective  Test  and  Evaluation  processes  have  been  executed  using 
the  AVS  and  the  Test  System.  The  key  results  of  the  Test  and  Evaluation  process  are: 

a  MIL-STD-1760  Evaluation  Report  (to  enable  the  AEIS  to  be  correctly  specified). 
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b.  MIL-STD-1760  Test  Plan  (to  enable  MIL-STD-1760  implementations  to  be 
validated). 

The  test  and  evaluation  process  involves  the  following  tasks  to  achieve  these  results: 

a  MIL-STD-1760  Test  Plan  generation 

b.  MIL-STD-1760  Test  Plan  execution 

c.  AVS  Evaluation 

d.  MtL-STD-1760A  Evaluation 

e.  MIL-STD-1760  Logical  Design  Definition  (LDD)  Evaluation 

These  are  described  in  sections  5.3.1  through  5.3.5  below,  and  are  shown  in  figure  5.14. 

5.3.1  MiL-STD-176Q  Test  Plan  Generation  This  plan  identifies  each  individual  requirement  of 
MIL-STD-1760  and  describes  how  to  test  that  each  of  these  requirements  are  being  met.  The 
document  identifies  four  main  categories  of  testing  which  are: 

a  Inspection  -  Concerned  with  visual  verification  (non-operating)  of  equipment  or 
related  documentation. 

b.  Analysis  •  Process  by  which  the  design  is  examined  and  computation  based  on  this  is 
performed. 


c.  Demonstration  -  process  of  verification  of  a  qualitative  requirement  by  observing 
correct  operation. 

d  Measurement  •  Process  of  verification  by  exercising  applicable  elements  and 
collecting,  reducing  and  analyzing  data. 

The  MlL-STO-1760  test  plan  includes  a  test  matrix  which  for  each  of  the  requirements 
identifies  which  category  of  testing  is  required  and  the  approach  that  may  be  taken  to  perform 
those  particular  tests. 

5.3.2  MIL-STD-1760  Test  P'.an  Execution  The  test  requirements  identified  in  5.3.1  above 
were  used  as  the  basis  for  ensuring  the  AVS  correctly  implements  MIL-STD-1760.  Firstly 
those  tests  relevant  to  the  AVS  were  identified.  Then  a  detailed  procedure  was  generated  for  those 
tests  requiring  demonstrations  or  measurements  of  the  AVS.  This  procedure  was  then  performed 
to  obtain  the  necessary  data  to  be  analyzed.  Reports  were  then  generated  against  each  of  the 
relevant  requirements  and  these  individual  reports  collected  together  and  summarized  to 
produce  the  MIL-STD-1760  Test  Report. 

5.3.3  AVS  Evaluation  An  evaluation  of  the  AVS  design  is  required  to  ensure  that  tho 
MIL-STD-1760  Test  and  evaluation  processes  take  place  in  a  realistic  context;  that 's.  a  design 
representative  of  an  on-aircraft  AEIS.  This  evaluation  is  achieved  by  first  (>roducing  an  AVS 
Evaluation  plan  which  identifies  the  major  evaluation  topics  to  be  considered  and  then  for  each  of 
these  topics  identifies  the  detafled  issues  to  be  address^.  The  plan  also  indicated  for  each  issue 
the  approach  to  be  adopted  for  the  evaluation  in  terms  of  three  main  evaluation  methods: 

a  Analysis  -  process  of  examining  ttte  AVS  design 

b.  Measurement  -  process  of  exercising  applicable  elements,  collecting  data  and 
analyzing  the  results  obtained 

c.  Inspection  -  process  of  viewing  applicable  elements 
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MIL-STD-1760 


A  detailed  procedure  was  then  oenerated  tor  those  evaluation  requiring  measurements.  These 
procedures  were  then  performed  to  obtain  the  necessary  data  to  be  analyzed.  Reports  were  then 
generated  against  each  issue  and  these  incfividual  reports  collected  together  and  summarized  to 
produce  the  AVS  Evatoation  R^rt. 
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5.3.4  MIL-STD-176QA  Evaluation  This  evaluation  process  is  perlormed  in  order  to  determine 
the  impact  that  the  electrical  aspects  of  MIL-STD-1760A  has  on  the  design  of  the  AVS.  The 
evaluation  was  performed  by  first  producing  a  MIL  STD'1760A  Evaluation  plan  which 
identifies  the  major  Topics  to  be  considered  and,  for  each  Topic  identifies  the  detailed  issues  to  be 
addressed.  The  plan  indicates  the  approach  to  be  adopted  for  the  evaluation  in  terms  of  the  three 
main  methods,  Analysis,  measurement  and  inspection  as  defined  in  5.3.3  above.  A  detailed 
procedure  was  then  generated  for  those  evaluation  issues  requiring  measurements.  These 
procedures  were  then  performed  to  obtain  the  necessary  data  to  be  analyzed.  Reports  were 
generated  against  each  issue  and  these  individual  reports  collected  together  and  summarized  to 
produce  the  MIL-STD-1760A  Evaluation  report. 

5.3.5  MIL-STD-176Q  Logical  Design  Definition  (LDDt  Evaluation  This  evaluation  process  is 
performed  in  order  to  determine  the  impact  that  the  Logical  aspects  of  MIL-STD-1760  has  on 
the  design  of  the  AVS.  The  evaluation  is  performed  by  first  producing  an  LDD  evaluation  plan 
which  identifies  the  requirements  of  the  MIL  STD- 1760  Logical  Design  Definition  and  then 
defines  specific  issues  associated  with  these  requirements.  An  LDD  Evaluation  procedure  was 
then  generated  which  defines  the  approach  to  be  adopted  for  evaluating  those  issues  relevant  to 
the  AVS.  These  procedures  were  then  performed  and  a  report  generated  for  each  issue.  These 
individual  reports  were  then  collected  together  and  summarized  to  produce  the  LDD  Evaluation 
report. 

5.4  Summary  of  Results  of  Test  and  Evaluation  The  detailed  results  of  the  Test  and  Evaluation 
process  are  embedded  in  the  Application  Guidance  of  this  document  and  in  the  reports  referenced. 
A  summary  of  the  results  is  given  below  for  the  following  areas;  MIL-STD-1760  Evaluation, 
MIL-STO-1760  Test  Plan,  and  AVS  Evaluation. 

5.4.1  MIL-STD  1760  Evaluation  The  evaluation  of  MIL-STD-1760  based  on  the  experience  of 
designing  and  building  the  AVS  has  shown  that  an  AEIS  can  be  built  for  an  on-aircraft  situation 
which  implements  the  requirements  of  MIL-STO-1 760.  The  evaluation  did  show  some  areas  of 
concern  and  these  are  highlighted  in  the  following  paragraphs. 

5.4.1. 1  Evaluation  of  Electrical  Definition  Generally  the  electrical  requirements  specified  in 
MIL-STD-1760  can  readily  be  incorporated  in  the  design  of  a  stores  management  system,  the 
actual  interface  being  simpler  than  some  existing  stores.  There  are  two  areas  in  particular 
which  require  further  consideration:  fault  isolation  requirements  on  power  signals,  and 
provision  of  RF  networK  for  High  Bandwidth  1  signals.  These  are  discussed  below: 

a  Fault  Isolation  -  The  particular  requirements  of  MIL-STD-1760  impose  the  use  of 
circuit  breakers  in  series  with  each  of  the  power  signals  at  the  ASI.  No  other  suitable  devices 
have  been  found  which  meet  the  current-time  profile  specified  in  the  standard.  Circuit  breakers 
are  relatively  large  devices  and  could  present  difTiculties  if  available  space  is  limited. 

b.  RF  Network  •  The  requirements  of  High  Bandwidth  1  include  the  provision  of  a 
network  to  transfer  signals  up  to  1 .6  GHz.  To  ensure  that  all  the  requirements  of  this  network 
are  met  then  the  use  of  specialized  RF  relays  is  required.  These  devices  are  relatively  large  and 
result  in  the  volume  of  circuitry  required  to  implement  this  network  becoming  quite  significant. 
One  possible  solution  would  be  to  make  the  use  of  this  network  optional  and  so  allow  the  aircraft 
to  only  provide  this  RF  capability  at  selected  stations. 

5  4.1.2  Evaluation  of  Logical  Design  Definition  (LDDt  Evaluation  of  the  LDD  based  i4X)n  the 
experiences  of  the  AVS  implementation  has  shown  that  the  predicted  benefits  in  the  ares  of 
interoperability,  reduction  of  software  and  integration  cost  have  become  a  reality.  The  AVS  SMS 
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implementation  has  proved  that  an  aircraft  system  can  be  developed  with  a  generic  LOD  handling 
software  module  that  can  control  and  release  intelligent  mission  stores  using  with  typical  data 
fk>w  structure  in  LOD  formats  arxf  transmitted  within  the  LOD  protocols  that  would  be  expected 
in  controlling  modem  missiles.  The  evaluation  result  dearly  showed  that  the  following  areas 
yielded  the  expected  benefits: 

Standard  coordnate  systems,  formats  and  scalings  of  entities 
Standard  Messages  for  Safety  critical  control 
Specified  use  of  MIL-STD-1^  Status  word  bits 
Store  Description  Page  A 

Safety  critical  states  allowing  finite  state  control  software 

The  following  aspects  require  attention  to  improve  the  useability  of  the  LDD: 

Store  Descrfotion 
Service  Request 
Standard  Control  Words 
Safety  critical  Control 
Busy 

T.hese  are  discussed  in  the  paragraphs  below: 

a  Store  Description  •  It  was  possible  to  develop  generic  software  nxxfoles  for  message 
processing  using  the  uploaded  descriptions.  However,  the  context  of  each  user  defined  message; 
that  is,  at  which  point  during  the  release  sequence  the  message  is  required  and  the  rate  that  the 
message  is  to  be  transmitted,  is  not  supplied  by  the  mission  store  in  its  store  description.  The 
lack  of  this  information  compromises  the  interoperability  advantages  provided  by  store 
descriptions,  to  the  extent  that  store-specific  software  still  has  to  be  developed  in  the  aircraft 
system. 

b.  Service  Request  •  The  provision  of  queuing  up  to  4  events  at  the  mission  store  and  the 
resultant  protocol  to  support  this  proved  to  be  cumbersome  and  over  complicated  the  software 
design.  The  Standard  vector  word  created  problems  within  the  aircraft  software  solutions  in 
recovery  actions.  The  reporting  of  checksum  failure  through  service  request  over  complicated 
buffering  of  messages  to  allow  recovery  action  to  be  taken. 

c.  Standard  Control  Data  Words  -  The  use  of  standard  data  words  for  control  of  mission 
stores,  as  demonstrated  by  the  Discrete  Control  Word  l ,  can  result  in  increased  integration 
times  unless  the  precise  use  of  the  control  bits  is  specified.  It  also  proved  difficult  to  map 
mission  store  functions  onto  available  control  bits. 

d.  Safety  Critical  Control  Word  •  Imposing  a  strict  state  change  sequence  upon  mission 
stores  can  decrease  store  run  up  times  and  increase  store  design  complexity.  A  better  sofotion 
would  be  to  make  provision  for  full  sequence  to  be  implemented  by  the  mission  store  if  the  store 
requires  it. 

e.  Busy  Times  •  The  benefits  in  increasing  data  throughputs  by  utilizing  the  uploaded 
busy  times  cannot  easily  be  realized.  An  aircraft  impiementatK)n  capable  of  handling 
simultaneous  busy  RTs  with  different  busy  times  increases  the  complexity  of  the  BC  firmware  to 
such  an  extent  that  the  resultant  overhead  outweighs  the  possible  throughput  benefits. 

5.4.2  MIL-S7D-176Q  Test  Plan  The  execution  of  the  Test  Plan  on  the  AVS  showed  that  the 
system  complied  with  all  the  requirements  for  an  AEIS  as  defined  in  Draft  MIL-STD-1760A, 
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dated  April  1985;  and  Draft  MIL-ST0-176CA  Notice  1,  dated  3  June  1985;  as  limited  by  COC 
document  182-60-22. 


5.4.3  AVS  Evaluation.  The  Evaluation  process  showed,  that  the  system  was  representative  of  an 
on  aircraft  AEIS  implementation  in  all  issues  that  were  considered  and  were  relevant  to 
evaluating  M!L-STD-1760.  AVS  LRU  shape,  size  and  weight  were  rwt  always  representative  of 
aircraft  equipment,  but  this  did  not  invalidate  the  evaluation  of  MIL-STO-1760. 
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SECTION  6 


MIL-STD-1760  IMPLEMENTATION  CASE  STUDY 


6.1  PURPOSE  AND  SCOPE  OF  THE  CASE  STUDY  MIL-STD-1760.  the  Aircraft/Store  Electrical 
Interconnection  System  (AEIS),  is  beginning  to  significantly  affect  the  aircraft  and  store 
development  communities  as  pressure  is  increased  to  provide  more  interoperable  stores.  The 
standard  requires  that  new  stores  be  controllable  via  a  subset  of  the  MIL-STD-1760  signal  set, 
at)d  that  aircraft  be  capable  of  prcviding  the  MtL-STD-1760  Signal  Set.  No  aircraft  or  stores 
currently  fully  conform  to  1760,  altf.ough  some  feature  partial  implementations.  These  subsets 
are  varied  and  are  somehmes  arbitrarily  implemented  in  the  absence  of  sufficient  management 
directior^. 

6.1.1  Purpose  The  purpose  of  this  case  study  effort  is  tc  identify  and  address  issues  which  will 
be  faced  when  implementing  MIL-STD-1760  in  a  current  U.S.  fighter  aircraft,  this  objective 
being  achieved  through  the  practical  study  of  an  existing  aircraft.  The  information  produced  by 
this  study  should  provide  a  baseline  from  which  an  advanced  system  design  satisfying  1 760 
requirements  can  be  developed.  It  will  certainly  identify  typical  1760  implementation  issues 
and  how  they  were  resolved  in  this  case. 

6.1 .2  Scope  The  scope  of  the  study  was  limited  to  the  system  components  currently  aboard  the 
aircraft  which  would  be  affected  by  the  implementation  of  MIL-STD-1760.  These  comoonents 
generally  'eside  in  the  aircraft  Stores  Management  System;  however,  some  avionics  subsystems 
are  also  affected  by  1760,  and  these  are  also  addressed  in  the  study. 

6.1.3  Approach  The  overall  approach  taken  in  the  study  was  constrained  by  the  requirement  to 
retain  as  many  of  the  existing  aircraft  hardware  and  software  capabilities  as  reasonably 
possible,  and  accommodate  both  existing  and  projected  stores  in  the  baseline  for  the  advanced 
design.  Tne  approach  consisted  of  four  rask  areas:  MIL  STD-1760  tamilia.ization,  aircraft  data 
collection,  determination  of  implementation  impact  on  ihe  aircraft  through  analysis  and  tradeoffs 
of  alterna,  ves,  and  the  implementation  of  MIL-STD-1760.  The  case  study  has  been  separated 
into  two  parts; 

a  those  aspects  of  the  aircraft  wiring,  power  and  video  distribution  subsystem,  and  the 
Remote  Interface  Units  (RIU)  which  are  impacted  by  implemented  MIL-STD-1760. 

b.  the  design  impact  on  the  Advanced  Central  Interface  Unit  (ACIU)  of  implementing  all 
three  elements  of  MIL-STD-1760. 

6.2  CASE  STUDY  AIRCRAFT  (F-16C/Dt  The  F-16  C'D  was  the  logical  choice  for  the  case  study 
as  it  is  the  most  modern  U.S.  fighter  aircraft  with  the  potential  for  being  in  active  service  for 
many  years  to  come.  It  is  a  certainty  that  1760  stores  will  eventually  be  carried  by  the  F-16 
and  the  aircraft  will  have  to  be  modified  accordingly.  Further,  the  F-16  has  a  modern  digital 
avionics  suite  which  should  be  capable  of  supporting  1760  interfaces  with  minimal  change. 

These  features  were  considered  advantageous  since  it  was  expected  that  full  1760 
implementation  on  the  aircraft  also  would  eventually  be  required  for  a  number  of  reasons. 
Therefore,  the  study  would  provide  an  independent  baseline  for  future  decisions  on 
implementation  costs  and  technical  matters.  While  the  study  has  reviewed  current  plans  to 
implement  1760  on  the  F-16,  it  must  be  stressed  that  if  any  conclusions  reached  as  a  result  of 
this  study  differ  from  those  solutions  actually  being  implemented:  it  Is  not  a  critique  of  the 
planned  approach  by  the  aircraft  prime  contractor.  This  study  has  not  taken  into  account  cost 
and  timescale  implementation  issues.  We  vrould  wish  *o  thank  the  prime  contractor  for  their 
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support  during  this  study.  The  following  paragraphs  address  those  F-16  C/D  systems  which 
were  determinea  to  be  affected  by  implementation  of  a  1760  system.  A  general  description  of  the 
F-16  C/D  operational  characteristics,  along  with  a  brief  discussion  of  its  current  and  projected 
stores  management  capabilities  is  presented  initially.  This  is  followed  by  a  description  of  the 
current  and  projected  stores  for  the  aircraft  with  illustrations  of  loadouts  and  identifications  of 
control  requirements.  Next,  the  partial  1760  provisions  which  are  currently  featured  in  this 
aircraft  are  discussed.  Finally,  detailed  descriptions  of  the  system  components  and  their 
functions,  which  would  be  effected  by  full  implementation  of  1760,  are  provided. 

6.2.1  General  The  F-16  (C  and  D  models)  aircraft  are  single-engine,  multi-role  tactical 
fighters  with  full  air-to-air  and  air-to-ground  combat  capabilities.  The  F-16D  has  the  same 
characteristics  as  the  F-16C  except  that  it  is  a  tandem  two-place  aircraft.  The  aircraft  is 
powered  by  a  turbo  fan  engine  which  is  in  the  25,000-pound  thrust  class.  A  tricycle  landing 
gear  is  used.  All  flight  control  surfaces  are  actuated  hydraulically  by  two  independent  hydraulic 
systems  that  are  directed  by  signals  through  a  fly-by-wire  system.  The  cockpit  is  enclosed  by 
an  electrically  positioned  clamshell  canopy.  The  key  capabilities  required  for  the  dual  roles  of 
all  weather  air-to-ground  strike  and  air-to-air  superiority  include  the  following:  precise  fire 
control,  upfront  accessible  controls,  multifunction  displays,  accurate  navigation,  efficient  data 
processing  and  transfer,  and  most  important,  a  highly  capable  Stores  Management  System  for 
aircrew  management  of  both  simple  and  complex  stores.  This  involves  the  following  functions 
associated  with  the  management  of  the  stores: 

identification,  inventory  and  status 

activation  and  control 

release,  launch  and  jettison 

sequencing  and  delivery  rate 

verification  of  stores  and  system  integrity 

video  switching 

power  control 

coordinated  communications  between  the  cockpit  displays, 

delivery  avionics,  and  suspension  and  release  equipment 

In  addition,  advanced  capabilities  envisioned  for  the  future  imply  that  accommodations  may  have 
to  be  implemented  to  improve  the  ratio  between  target  destruction  and  the  attrition  costs  of 
expensive  aiicraft  for  items  such  as: 

a  Automatic  interrogation  by  Forward  Air  Control  (FAC)  elements  and  automatic 
transfer  of  ordnance  status  to  FAC  aircraft 

b.  In-flight  sight  depression  angle  calculations  involving  calculation  of  dv^pression  angle 
for  weapon  release  based  on  new  delivery  tactics  dictated  at  time  of  weapon  delivery 

c.  Safe  separation/dudding  check,  including  checking  cf  arming/fusing  conditions  to 
ensure  safe  separation  and  avoid  dudding 

d.  Bias  error  compensation  for  ordnance  bias  errors  such  as  ejection  velocity  and 
position  on  aircraft 

e.  In-flight  fuze  settings  whereby  the  fuze  setting  that  will  optimize  weapon 
effectiveness  is  calculated  based  on  release  conditions  and  target  kill  parameters 

f.  Aided  weapon  selection  whereby  a  computer  calculates  which  weapon  will  be  most 
effective  against  a  particular  target  and  within  various  release  conditions 
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6.2.2  Current  and  Projected  Stores  Figure  6-1  shows  the  typical  store  station  arrangements 
for  all  classes  of  stores  projected  for  deployment  on  the  F'16  C/D.  Figure  6-2  shows  the 
station  loading  authorizations  for  the  individual  stores  with  aircraft  electrical  interface 
requirements  which  are  currently  certified  for  the  aircraft,  and  those  projected  for 
certification.  The  various  quantities  authorized  for  each  store  station  and  the  mixes  between 
stations  can  be  found  in  the  station  loading  sheets  contained  in  Technical  Order  1F-16C-1  for  all 
currently  certified  stores.  The  entries  for  the  projected  stores  are  based  on  analogies  with 
current  stores  or  best  qualified  judgments. 

6.2.2. 1  Constraints  -  The  carriage  and  release  limitations  of  interest  which  have  been 
published  on  the  currently  certified  stores  are  as  follows: 

a  Mirror  images  of  all  authorized  store  loadings  are  authorized  unless  specifically 
restricted. 

b.  ECM  pods,  travel  pods,  AIM-9  missiles  and  ACMI  pods  are  non-jettisonable. 

C.  AN/ALQ-1 19/15,  AN/ALQ-1 19/17,  and  AN/ALQ-131  mixes  not  authorized. 

d.  Any  combination  of  AIM-9  missile  configurations  may  be  mixed. 

e.  ACMI  pod  may  be  substituted  for  any  AIM-9  missile  in  the  authorized  air-to-air 
loadings. 

f.  Launch  sequence  of  AIM-9  missiles  is  from  inboard  to  outboard.  Only  one  step-over 
per  wing  is  authorized. 

g.  Empty  AIM-9  launchers  at  stations  2  and  8  not  authorized  for  carriage  when  nuclear 
weapons  are  carried. 

h.  Air-to-surface  stores  of  same  type  must  be  separated  outboard  to  inboard. 

i.  Air-to-surface  stores  in  mixed  loads  may  be  separate  inboard  to  outboard;  however, 
all  stores  of  one  type  must  be  deployed  before  initiating  deployment  of  another  type. 

j .  When  300  and  370/600  gallon  fuel  tanks  are  carried  simultaneously,  the  300  gallon 
tank  must  be  separated  prior  to  separation  of  370/600  gallon  tanks. 

k.  Minimum  release  interval  for  unretarded  stores  is  60ms  for  ripple  pairs  from  TERs. 

l .  For  single  stores  of  the  same  kind  on  stations  3.  4,  6  and  7,  the  minimum  release 
•n  ervals  are  200ms  for  pairs  and  100ms  for  singles. 

m.  Minimum  release  intervals  for  retarded  stores  is  150ms  for  pairs  and  75ms  for 
singles  from  TERs. 

n.  For  single  mixed  stores  on  stations  3,  4,  6  and  7,  the  minimum  release  intervals  are 
250ms  for  pairs  and  I25ms  for  singles. 

o.  Selective  and  emergency  jettison  lor  nuclear  stores  can  be  accomplished  only  be  using 
normal  SMS  release  procedures. 
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FIGURE  6.1  Typical  External  Store  Station  Arrangement  and  Store  Interface  Compatibility 
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FIGURE  6.2  Store  Station  Authorizations  for  External  Stores  with  Electrical  Int  face 

Requirements 
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*  Protected  Stores  4  Planned  MIL-STD-1760  stores 

(1)  Loading  Authorizations  Symmetric  except  for  lAGTS  and  LANTIRN:  see  Remarks 


6. 2. 2.2  Store  Control  Requirements  -  The  stores  listed  in  figure  6.3  have/will  have  control 
requirements  which  must  be  aocom modeled  by  the  F-16  C/D  Stores  Management  System  (SMS). 
These  requirements  are  well  ur  derstood  for  stores  which  are  documented  in  publications  such  as 
Weapon  interface  Data  Summaries  (WIDS);  AAAS  Contractor  Stores  Data  (ACSD);  AAAS  Stores 
Digital  Interface  Data  (ASDID);  and.  the  Aircraft  Stores  Interface  Manual  (ASIM).  The 
documents  which  describe  the  requirements  for  a  given  store  are  identified  in  the  remarks 
column  for  the  store  listing.  The  following  information  is  provided  for  stores  listed  in  figure 
6.3  which  are  not  included  in  the  aforementioned  information  sources  (WIDS,  ACSD,  ASDID, 
ASIM)  and  for  wliich  little  definitive  store  control  information  was  available. 


Stor* 

Ramarka 

Store 

Ramarka 

ACMI 

A-A  Combat  acorine  pod 

lAGTS* 

Improved  A-A  37u-33 

mounia  to  AIM-9  launchar 

Aerial  Target 

AGM-6S 

WIOS-21.  21-A,  ASOIO-1.4 

lantirn* 

1  Targeting  pod, 

1  Navigational  pod 

AGM-iaO* 

Powarad  GBU-1S 

LAU-3 

FFAR  (19)  launchar 

AIM-7 

ASOIO-1,  3 

LAU-68 

FFAP  ('/)  launcher 

AIM-9 

WIDS-4,  ACSO-2. 

ASOIO-1.2 

LAU-88 

3  rail  Maverick 
launcher  WIDS-20 

AN/ALQ-119 

ECM  Pod 

cAU-IIS* 

AMRAAM  Launcher 

AN/ALQ-131 

ECM  Pod 

ASDID-I,  10 

AN/mLQ-165’ 

Adv.  Saif  Protection 

LAU-117 

tingle  rail  Maverick 

Jammer  (ECM  Pod) 

launcher  WIOS-20, 

ASDID-4 

AMRAAM* 

ASOiD-1.10 

LAU-S003 

CRV7  (19)  lauchar 

ASHAAM* 

Advanced  Short  Itanga  A-A 
Miaaila 

LRSOM* 

next  generation  atand-off 
mitaila 

B-57 

NUKE  Syaivm  1  Interface 
with  NRIU 

MAU-12 

pylon  internal  rack, 

WIDS-20,  ASIM 

B-61 

NUKE  Syatem  1  Intenaca 
with  NIRU,  ACSO-26 

M61  A1 

20MM  internal  gun 

BRU-31 

ASIM  (aama  aa  TER-9), 
WIOS-20 

OBEWS* 

EW  training  ayatam 

SRARM* 

Short  range  and- 

FUEL  TA'HKSj 

370  &  600  gala 

radiation  miaaila 

GBU  15 

20001b  glide  bomb  (EO) 
ACSD-22 

SAIF* 

programmable  fuze 

j  *  CONCEPT  /  DEVELOPMENT 

FIGURE  6.3  Currently  CertiFied  and  Projected  Stores  with  Electrical  Control  Requirements 
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a  The  Air  Combat  Maneuvering  Instfumentation  (ACMH  range  system  contains  two 
airborne  pods  (AlS/P-4  and  AIM-7  TM)  which  simulate  respectively  the  carriage  and  launch  of 
AIM-9  and  AIM  7  air-to-air  missiles.  Both  pods  have  unique  1553  A-MUX  links  with  the  host 
aircraft,  but  interface  with  the  AIM-9  Launcher  for  other  electrical  requirements,  duplicating 
those  of  the  AIM-9.  However,  new  acquisitions  of  these  pods  beginning  in  FY-87  are  required  to 
comply  with  MIL-STD-1760. 

b.  The  AGM-130  is  a  powered  version  of  the  GBU-15  Glide  Bomb  and  is  currently  in  the 
advanced  stages  of  development.  Up  to  three  times  the  range  of  the  GBU-15  is  expected  by  the 
addition  of  propulsion.  The  SMS  control  requirements,  except  for  the  propulsion  unit,  are 
expected  to  be  essentially  those  associated  witn  the  GBU-15  and  are  outlined  in  ACSD-22. 

Another  possible  exception  may  be  a  requirement  for  precise  inertial  alignment  data  if  a  lock- 
on-after-launch  capability  requiring  navigation  to  a  waypomt  is  developed  for  the  weapon. 

c.  The  AN/ALQ-119.  131  and  165  are  ECM  pods  which  can  be  carried  on  stations  3,  5, 
and  7.  They  are  never  mixed;  only  one  of  the  configurations  can  be  flown  during  a  mission.  The 
AN/ALQ-165  is  known  as  the  Advanced  Self-Protection  Jammer  and  is  currently  in  the  final 
stages  of  development.  The  pods  have  no  direct  interface  with  the  SMS  except  they  must  be  loaded 
into  the  SMS  memory  to  provide  AC  power  to  the  pods. 

d.  The  Advanced  Short  Range  Air-to-Air  Missile  (ASRAAM^  began  as  a  joint  USAF/USN 
venture  which  was  allocated  to  UK/FRG  after  a  Memorandum  of  Understanding  (MOU)  was  signed 
for  European  participation  in  the  program.  ASRAAM  is  to  be  a  replacement  for  the  AIM-9  family 
of  IR  homing  missiles.  A  UK/FRG  company  called  BBG  (Bodenseewerk,  British  Aerospace, 

GmbH)  was  formed  in  November  of  1983  to  carry  out  development  and  production  of  ASRAAM. 
Little  is  known  about  the  status  of  the  program  except  that  a  lock-on-after-launch  capability, 
desired  by  the  US.  is  being  debated  among  the  participants. 

e.  The  F-16  external  fuel  system  includes  three  tanks  of  different  capacities  (300.  370 
and  600  gallons)  which  can  be  carried  in  various  combinations.  The  300-gallon  tank  is  carried 
only  at  the  fuselage  centerline  station  on  a  MAU-12  and  has  no  electrical  interface  with  the  SMS. 
The  370-  and  600-gallon  tanks  only  can  be  carried  on  stations  4  and  6  on  fuel  pylons.  The  SMS 
interfaces  with  the  fuel  pylon  for  store  present  indication  and  for  cartridge  fire  to  jettison  the 
pylon-tank  combination. 

f.  IheJmproved  Aerial  Gunnery  Target  System  (lAGTSI  is  a  captive  targm  towed  hy  an 
aircraft.  The  target  is  contained  in  a  pod,  reeled  in  at  mission  completion.  lAGTS  control 
requires:  aircraft  power;  power  for  jettison,  reel  out/in,  counter  reset  and  data  for  cable 
length,  scoring,  system  status,  and  display  thereof.  A  MIL-STD-1760  interface  is  a  system 
requirement;  however,  the  system  specification  does  not  call  for  its  incorporation  until  such 
time  as  a  pre-planned  product  improvement  (P3|)  program  is  initiated. 

9-  The  LANTIRN  targeting  and  navigation  system  is  in  advanced  siagps  nf  ripvpiftpmont  gnH 
will  greatly  enhance  the  capabilities  of  the  F-16  upon  eventual  deployment.  The  system  consists 
of  two  pods:  one  for  targeting  which  includes  a  laser  transmitter/receiver  and  a  FLIP,  the  other, 
for  navigation,  includes  a  Terrain  Following  Radar  (TFR)  and  a  FLIR.  The  navigational  pod  has  no 
interlace  with  SMS.  The  targeting  pod  has  a  serial  digital  interface  with  the  SMS  for  control  of 
mode.  Field-of-View  (FOV)  contrast,  and  AGM-65  Maverick  target  handoff.  both  automatic  and 
manual.  Postulated  advanced  versions  of  LANTIRN  would  also  have  the  capability  to  automatically 
target  up  to  six  Mavericks  (or  other  video  type  weapons)  simultaneously.  This  capability  is 
piobably  5  to  10  years  in  the  future. 
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h.  The  LAU-3.  68  and  5QQ3  are  2.75-inch  rocket  launchers  carried  on  the  centerline 
stations  of  Triple  Ejector  Racks  (TER).  An  intervalometer  within  each  launcher  is  ground 
settable  for  interval  and  firing  mode  (single/ripple).  Firing  signals  from  the  SMS  are  routed  to 
the  launchers  through  the  TER  by  a  selector  switch  located  on  the  aft  end  of  the  TER.  Rocket 
capabilities  for  the  launchers  are:  LAU-3  (19);  LAU-68  (7);  and  LAU  5003  (19).  CRV7 
rockets  are  loaded  in  the  -5003  as  opposed  to  FFARs  for  the  -3  and  -68. 

i .  The  Long  Range  Standoff  Missile  (LRSOMt  program  is  just  now  getting  started  with 
concept  definition  contracts  awarded  to  two  teams  or  contractors  headed  up  by  Boeing  and  General 
Dynamics  (GO).  Several  European  countries  are  represented  on  the  two  teams.  At  this  time  the 
concept  appears  to  be  leaning  toward  the  cruise  missile  approach  with  a  variety  of  conventional 
munition  warheads,  ^th  lead  contractors  have  developed  cruise  missiles:  Boeing,  the  AGM-86 
ALCM;  and  GO,  the  AGM-109  Tomahawk  in  ground  and  sea  launched  configurations.  GO  also  was 
well  into  developing  an  air  launched  configuration  of  the  Tomahawk  called  Medium  Range  Air-to- 
Surface  Missile  (MRASM)  for  conventional  weapon  warheads  before  the  program  was  canceled. 

It  is  highly  probable  that  LRSOM  will  be  developed  with  a  MIL-STD-1760  interface.  Envisioned 
capabilities  of  LRSOM  imply  that  the  SMS  store  control  requirements  will  include,  as  a 
minimum:  power  conditioning;  inertial  alignment;  flight  support  systems  checkout  and 
initiation;  payload  programming;  sensor  activation;  and  launch/release. 

j .  The  Internal  Gun  Subsystem  M61A1  consists  of  cockpit  controls,  gun  controller, 
20mm  gun,  ammunition  handling  set,  gun  supports,  ventilation  system,  rounds  limiter  switch, 
and  last  round  byoass  switch.  The  gun  provides  close  range  air-to-air  and  air-to-ground 
combat  capabilities.  The  gun  is  located  at  the  left  strake  and  is  a  fixed,  air-cooled,  six-barrel 
weapon  which  is  coupled  with  a  510-round  capacity,  double-ended,  linkless-feed  ammunition 
handling  system.  Arming  of  the  gun,  display  of  stations  (ready/not  ready),  and  display  of  rounds 
count  are  required  of  the  SMS. 

k.  The  On-Board  Electronic  Warfare  Simulator  (QBEWSt  is  an  electronic  combat  (EC) 
training  aid  designed  to  provide  aircrews  with  realistic  EC  threat  indications  during  training 
flights.  OBEWS  will  be  housed  in  a  pod  nearly  identical  to  the  AN/ALQ-131  pod  and  interfaces 
with  the  SMS  only  for  power  control  as  do  the  ECM  pods. 

l .  The  Short  Range  Anti  Radiation  Missile  (SRARM)  program  was  scheduled  for  a  late 
1985  start  of  the  concept  definition  phase.  The  weapon  is  to  fulfill  NATO  requirements  for 
protection  of  aircraft  against  radiating  threats  while  operating  in  or  around  the  FLOT  (Forward 
Line  of  Troops)  areas.  The  threats  primarily  would  be  mobile  anti-aircraft  artillery  and 
surface-to-air  missiles  launched  from  vehicles  or  hand-held.  The  operational  concept  implies 
automatic  or  autonomous  launch  upon  threat  detection  allowing  the  aircrew  to  fully  concentrate 
on  the  primary  aircraft  mission.  Such  a  capability  will  place  significant  processing  demands  on 
aircraft  systems  for  target  acquisition,  discrimination,  and  launch  control.  It  is  assumed  that 
the  aircraft  interface  for  SRARM  will  conform  to  MIL-STD-1760  as  is  expected  for  all  new 
NATO  weapons.  The  SMS  control  requirements  could  be  quite  extensive  if  automatic/autonomous 
operation  becomes  an  eventual  capability. 

m.  The  Standardized  Avionics  Integrated  Fuze  (SAIR  is  being  developed  to  provide  an  in¬ 
flight  capability  for  programming  fuze  functions  consistent  with  release  conditions  and  target 
kill  requirements.  SAIF  features  a  subset  of  the  MIL-STD-1760  interface  and  currently 
consists  of:  MIL-STD-1553  MUX  Bus,  28  VDC  power;  and  discretes  for  interlock  and  return, 
five  address  lines  with  return,  and  address  parity.  SAIF  is  Intended  primarily  for  use  with 
unitary  warhead  and  dispenser  drop  weapons  with  few,  if  any,  sophistications  other  than  the 
programmable  fuze. 
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6.2.2.3  Impact  on  Stores  Management  -  Almost  all  of  the  projected  new  complex  stores  will 
have  a  MIL-STD-1760  interface  and  will  generally  exhibit  control  requirements  in  excess  of 
those  associated  with  existing  stores.  The  stores  will  require  more  avionics  type  information 
such  as  targeting,  air  data,  and  navigation.  Training  pods  like  the  ACMI  and  OBEWS  require  other 
types  of  information  not  normally  found  on  the  SMS  bus.  such  as  cockpit  switch  activations  and 
status  of  other  avionics  subsystems.  These  and  other  diverse  requirements  will  necessitate  a 
comprehensive  SMS/avionics  interface.  Also,  significantly  increased  SMS  processing 
requirements  will  occur  due  primarily  to  desired  capabilities,  such  as  autonomous  and 
simultaneous  control  of  stores  and  more  complex  store  processing  algorithms  associated  with 
store  targeting  and  navigational  data. 

6.2.3  F-16  C/D  Current  MIL-STD-176Q  Provisions  A  complete  aircraft/store  electrical 
interconnection  system  is  comprised  of  three  elements:  electrical,  logical,  and  physical.  The 
electrical  element  specifies  the  aircraft-to-store  interface  signal  set  and  associated  electrical 
characteristics.  The  logical  element  defines  aspects  such  as  the  communication  protocol,  formats 
for  messages  and  standard  data  words.  The  physical  element  specifies  the  mechanical  parameters 
necessary  for  achieving  intermateable  electrical  connections.  Of  these  three  elements,  the 
electrical  and  physical  elements  are  addressed  in  MIL-STD-1760A.  The  electrical  interface  is 
comprised  of  two  signal  sets,  a  Primary  Inte  _w'C  Signal  Set  and  an  Auxiliary  Power  Signal  Set. 
The  former  is  the  basic  signal  set  for  1760,  while  the  latter  is  for  those  applications  requiring 
additional  power.  The  logical  element  was  initially  released  as  draft  notice  1  to 
MIL-STD-1760A.  This  notice  has  been  used  as  the  reference  document  for  all  of  the  logical 
requirements.  Figure  6.4  lists  the  1760  electrical  requirements  and  shows  the  wiring 
provisions  made/to  be  made  by  the  airframe  manufacturer  for  the  requirements  in  both  the 
F-16  Blocks  15  and  25.  The  following  general  comments  are  provided  on  the  actual  provisions 
as  documented  in  the  information  and  data  reviewed  for  C/D  model  aircraft. 

a  RF  Lines  •  General  Dynamics  claims  to  have  installed  RF  lines  such  that  two  lines  are 
available  near  the  wing  disconnect  to  store  stations  3.  4.  6  and  7.  These  lines  terminate  in  the 
avionics  bay.  This  claim  could  not  be  verified. 

b.  Video  Lines  -  A  video  line  is  available  at  the  store  interface  of  stations  3,  4,  6,  and  7 
(Maverick  certified  stations).  For  the  air-to-air  stations  (1,  2,  3A,  7A.  8  and  9),  video  is 
available  at  the  wing/launcher  (adapter)  interface.  Given  that  3  and  3A  are  mutually  exclusive 
(same  for  7  and  7A),  the  video  lines  at  the  "A"  stations  could  be  utilized  as  a  second  line  to 
stations  3  and  7.  The  video  line  for  station  5  now  terminates  in  the  aircraft  near  that  store 
station. 


c.  3  Phase  AC  -  Primary  3  Phase  115  VAC  power  is  available  at  the  store  interfaces  of 
stations  3.  4,  6,  and  7.  Three  phase  power  is  available  for  station  5  at  the  ECM  connector  (see 
I'ollowing  comment  on  auxiliary  power).  For  the  air-to-air  stations,  one  phase  is  available  at 
the  interface  to  the  launcher  power  supply.  The  other  two  phases  are  present  near  the 
wing/launcher  (adapter)  interface. 

d.  28  VDC  Power  10  A/Line  -  At  stations  4  and  6.  28  VDC  is  present  at  the  store 
interface  with  a  maximum  current  capability  of  14.4  amps.  At  stations  3,  7,  and  the  air-to-air 
stations,  28  VOC  with  maximum  capability  of  10.8  amps  is  available. 

e.  Independent  Power  Control  -  Power  is  presently  switched  by  discretes  from  the 
Advanced  Central  Interface  Unit  (ACIU)  on  a  station-by-station  basis.  AC  and  DC  power  are 
controlled  together. 
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f.  Audio  -  Audio  lines  are  available  at  the  store  interface  of  the  air-to-air  stations. 
These  lines  are  used  to  feed  the  AIM-9  audio  into  the  aircraft. 

g.  Multiplex  1553B  -  The  1553  Avionics  Multiplex  (A-MUX)  Bus  is  available  at  the 
store  interface  of  stations  3,  4,  6,  7  and  at  the  fuselage  pylons  disconnect  of  station  5.  MIL- 
STD-1553  Weapons  Mux  (W-MUX)  capability  is  available  at  the  pylon  disconnect  for  the  air- 
to-ground  stations  and  at  the  wing  launcher  (adapter)  interface  for  the  air-to-air  stations.  The 
ACIU  has  already  been  modified  to  support  1553  W-MUX  protocol. 

h.  Interlock  -  Existing  capabilities  can  be  utilized  to  implement  the  interlock  line. 

i .  Structure  Ground  -  Structure  ground  is  available  at  the  store  interface  at  all  stations 
except  5.  For  station  5.  it  is  available  at  the  fuselage  pylon  disconnect. 

j .  Release  Consent  -  Safety  considerations  notwithstanding,  a  discrete  from  the  Remote 
Interface  Unit  (RIU)  could  be  utilized  for  Release  Consent. 

k.  Auxiliary  3  Phase  AC  Power  -  Three  phase  AC  power  presently  utilized  for  control  of 
ECM  pods  is  available  at  the  ECM/Store  interfaces  for  station  5,  and  at  the  ECM  connector  for 
stations  3  and  7.  Note  that  the  power  is  not  switched  by  the  Stores  Management  System. 

l.  Auxiliary  Interlock  -  Generally  available. 

m.  Auxiliary  Structure  Ground  •  Available. 

6.2.4  System  Components  affected  by  MIL-STD-176Q  Initial  studies  of  the  implementation 
requirements  of  1760  showed  that  the  affected  F-16  C/D  components  are  primarily  in  the 
Stores  Management  System  with  a  few  other  components  in  the  Video  Switch  and  Stores  Standby 
Power  systems.  The  following  paragraphs  provide  general  information  on  functions  of  these 
three  systems  along  with  more  detailed  descriptions  on  the  components  within  the  systems. 

6.2.4. 1  Stores  Management  System  (SMS)  •  The  F-16  C/D  AfJvanced  Stores  Management  System 
shown  as  a  block  diagram  in  figure  6.5  performs  the  following  functions: 

Store  identification,  inventory,  and  status 

Store  activation  and  control 

Store  release,  launch,  and  jettison 

Stores  sequencing  and  delivery  rate 

Verification  of  store  and  system  integrity 

Video  switching  and  power  control  at  the  weapons  stations 

The  SMS  provides  communication  linkages  between  the  pilot's  displays,  the  weapon  delivery 
avionics,  and  the  store  station  equipment.  One-man  delivery  is  facilitated  by  the  multifunction 
display  panel  which  provides  a  display  of  store  status  and  weapon  delivery  mode.  This  allows  the 
pilot  to  reprogram  delivery  options  in  flight  through  simple  keyboard  operations.  The  SMS 
functions  are  initiated  by  pilot  operated  switches  on  the  SMS  Multifunction  Display  (MFD)  or 
the  Integrated  Control  Panel  (ICP)  master  mode  panel,  implemented  by  the  Advanced  Central 
Interface  Unit  (ACIU)  arKl  accomplished  by  the  Remote  Interface  Units  (RIU). 

The  components  of  the  SMS  are  listed  below.  Although  not  defined  as  part  of  the  SMS,  the 
Launcher  Electronics  are  integral  to  stores  management  and  are  included  with  the  SMS 
component  descriptions  for  convenience.  The  functions  and  characteristics  of  these  components 
are  described  in  the  following  paragraphs 
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AVIONICS  POWER 

BUS  : 


FIGURE  6.5  F-16  C/D  stores  management  system  block  diagram 
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Advanced  Central  Interface  Unit  (ACIU) 

Advanced  Conventional  Remote  Interface  Unit  (ACRIU) 

AdvarKed  Missile  RIU  (AMRIU) 

Nudear  RIU  (NRtU) 

Jettison/Release  RIU  (J/R  RIU) 

Weapons  Multiplex  Bus  (W-MUX) 

MIL-STD-1553  Bus 
SMS  Software 
Launcher  Electronics 

6.2.4.1.1  Advanced  Central  Interface  Unit  (ACIU)  -  The  ACIU  performs  the  following  functions: 
Monitors  switch  actions  front  the  cockpit 
Monitors  tne  condition  of  the  stores 
Creates  commands  files  in  response  to  proper  inputs 
Outputs  croated  command  files  via  discretes.  W-MUX  Bus. 

Avionics  MUX  Bus  (A-MUX).  and  Display  Mux  Bus  (D-MUX) 

Maintains  store  inventory 
Performs  system  tests 

The  ACIU  is  informed  of  switch  actions  in  the  cockpit  via  discretes  and  digital  data  over  the  D- 
MUX  bus.  Status  information  on  the  stores  is  received  over  the  W-MUX  from  Remote  Interface 
Units.  These  inputs,  when  valid,  resu!.  in  command  files  being  built.  Such  outputs  take  on  of  the 
following  two  forms;  discretes  output  from  the  ACIU  (fiscrete  I/O  board,  or  messages  sent  out 
over  the  A-MUX,  0-MUX.  or  W-MUX.  Commands  intended  to  contfition  or  release  stores  go  out 
over  the  W-MUX  Bus.  C^mands  interKfed  to  update  displays  or  data  at  other  avionics  systems 
are  transmitted  over  the  A-MUX  or  D-MUX  busses.  If  these  commands  result  in  successful  store 
deployment,  the  ACIU  then  updates  the  stores  inventory.  The  firmware  which  controls  the  ACIU 
is  the  SMS  Operational  Flight  Program  (SMS  OFP).  Located  in  nonvolatile  memory,  the  SMS  OFP 
implements  the  functions  kfentified  above.  For  a  brief  description  of  this  program  see  paragraph 
6.2.4.1.8.  ACIU  hardware  consists  of  redund^t.  symmetric  processors  which  provide  general 
processirtg  capabilities  arnl  interface  with  other  elements  of  the  SMS  and  the  avionics  system, 
enabling  control  of  the  SMS.  The  ACIU  directs  the  Remote  Interface  Units  (RIU)  to  transmit 
store  control  signals,  arKi  in  turn  receives  currently  updated  store  status  from  the  station(s) 
RIUs.  These  administrative  functions  are  performed  by  a  stores  data  processor  through  the 
weapons  multiplex  interface  element.  The  processor  contains  memory  for  the  program  and  data 
storage  and  input/output  channels  for  signal  transfer.  Each  of  the  ACIU  microcomputer  systems 
consists  of  a  stores  data  processor,  a  DMA  RAM.  a  nonvolatile  memory,  MUX  Bus  interface 
elements,  and  a  fault  monitor.  The  stores  data  processor  consists  of  a  microprocessor  CPU  and 
the  necessary  processing  control  logic.  The  program  memory  consists  of  48K  bytes  of  non¬ 
volatile  programmable  memory.  It  is  in  this  merrKtry  that  the  executable  instructions  of  the  SMS 
OFP  reside.  The  DMA  RAM  is  1 6K  bytes  of  rhared  volatile  rarnlom  access  memory  (RAM),  and  a 
DMA  control  capability.  This  memory  is  used  for  data  storage  and  to  buffer  input/output  to  the 
A-MUX.  A  fault  monitor  detects  failures  in  each  of  the  processors  and  reports  these  failures  lo 
the  other,  so  that  if  necessary,  the  good  unit  can  take  over  all  processing  tasks.  It  monitors  the 
processor  logic  for  things  such  as  addressing  errors,  timing  errors,  clock  errors,  parity 
errors,  and  power  supply  failures.  The  fault  monitor  also  contains  a  loop  error  detection 
capability  to  provide  CPU  or  software  error  detection  capabilities.  The  ACIU  is  positioned  in  the 
fonward  equipment  bay  on  the  left  side  of  the  aircraft  just  forward  of  the  cockpit.  About  5000 
in3  are  available  in  the  bay,  occupied  by  radar,  communications,  and  other  miscellaneous 
components  in  addition  to  the  ACIU.  Some  volume  (approximately  1000  in3)  around  the  ACIU 
appears  avail^>le  for  limited  expansion  of  the  ACIU  without  having  to  relocate  other  equ'pment 
(This  corxtiusion  has  been  reacts  after  a  physical  inspection  of  the  equ^ent  bay). 
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6.2.4. 1 .2  Advanced  Conventional  Remote  Interface  Unit  (ACRIU)  -  The  ACRIU  provides  signals  to 
the  store,  reoorts  status  from  the  store,  sends  control  signals  to  the  Video  Switch  aruj  MAU-12, 
and  reports  status  from  the  MAU-12.  Linked  to  the  ACIU  by  the  W-MUX  Bus,  the  ACRIU  outputs 
ACIU  commanded  signals.  These  signals  fail  into  two  classes:  disaete  and  analog.  The  discrete 
signals  are  produced  by  switch  action.  Two  D/A  converters  provide  the  analog  signals.  In  older 
versions  (F-16A/B  CRIU)  all  of  these  signals  serviced  only  the  store  and  MAU-12,  but  as  the 
ACIU  discrete  I/O  board  became  saturated,  some  of  the  ACIU  controlled  discretes  were  moved  to 
the  ACRIU.  These  discretes  include  the  control  signals  to  the  Video  Switch,  Sel  Video  A  and  Sel 
Video  B.  The  ACIU  sends  commands  to  the  ACRIU  in  the  form  of  messages  over  the  W-MUX  Bus. 
The  ACRIU  responds  with  a  status  word  on  the  clock  of  the  second  GO/NO  GO  word.  Using  this 
status  word,  the  ACRIU  reports  the  condition  of  the  received  command,  the  results  of  that 
command,  and  the  status  of  the  store  ar>d  MAU-12  (pylon  ejector  rack).  One  ACRIU  is  located  at 
each  air-to-ground  weapons  station  writhin  the  weapons  pylons  at  stations  3,  4,  6  and  7  and 
within  the  centerline  pylon  for  station  5.  Additional  space  in  the  weapons  pylons  near  the 
current  CRIU  locations  is  limited;  however,  some  other  weapons  pylon  areas  offer  available 
space  should  expansion  of  the  ACRIU  be  necessary.  This  would,  however,  require  allocating 
ACRIU  functions  to  multiple  small  packages.  These  areas  are  associated  with  the  forward  and  aft 
pylon  fairings,  the  J907  and  J917  receptable  location,  and  the  safety  pin  storage  compartment 
which  offers  the  greatest  volume,  approaching  some  430  in^.  The  centerline  pylon  is 
considerably  smaller  than  a  weapons  pylon  although  some  space  could  be  made  available  in  the 
forward  and  aft  fairing  areas  and  imm^iately  aft  of  the  ACRIU  mounting  structure.  The  weapons 
pylons  are  interchangeable  between  stations  3, 4,  6  and  7  and  contain  both  the  ACRIU  and  the 
Nuclear  Remote  Interface  Unit  (NRIU).  The  ACRIU  must  be  removed  from  the  centerline  pylon 
before  an  NRIU  can  be  installed. 

6.2.4. 1.3  Advanced  Missile  Remote  Interface  Unit  (AMRIU)  -  The  AMRIU  outputs  control  signals 
to  missiles,  controls  the  conditioning  signals  from  the  launt^er  power  supply,  switches  analog 
feedback  signals  from  the  missiles,  and  reports  missile  status  and  the  accomplishment  of 
requested  actions.  Linked  to  the  ACIU  by  the  W-MUX  Bus,  the  AMRIU  outputs  control  signals  and 
closes  relays  in  response  to  ACIU  commands  sent  in  the  form  of  data  words.  Using  protocols 
defined  in  paragraph  6.3.1. 1.6,  the  AMRIU  also  returns  status  words  to  Lhe  ACIU.  In  these  status 
words,  the  AMRIU  reports  the  condition  of  the  store  and  of  received  commands.  The  AMRIU  is 
located  at  stations  1 ,  2,  3A,  7A,  8  and  9  when  these  stations  are  configured  for  air-to-air 
weapons.  The  AMRIU  is  located  in  the  extreme  aft  end  of  each  missile  launcher.  The  launchers  at 
stations  1  and  9  are  bolted  directly  to  the  tips  of  the  wings.  Launchers  at  stations  2,  3A,  7A  and 
8  are  attached  to  launcher  adapters.  Unused  space  in  the  launcher  is  limited  to  a  couple  of  inches 
aft  of  the  AMRIU;  however,  the  launcher  adapter  offers  some  possibilities  foi  aciditional 
hardware  as  the  cutouts  and  fairings  are  empty  except  for  an  umbilical  which  passes  through  the 
forward  fairing. 

6  2.4.1.4  Nuclear  Remote  Interface  Unit  -  Nuclear  RIUs  can  be  installed  at  stations  3,  4,  5,  6 
and  7,  but  are  not  necessarily  carried  during  non-nuclear  or  training  missions.  Specifics  on  the 
operation  of  these  units,  however,  is  beyond  the  classification  of  this  docurnent.  The  NRIU  is 
located  in  the  aft  portion  of  the  weapons  pylon,  and  interchanges  with  the  ACRIU  in  the  centreline 
pylon. 

6.2.4. 1.5  Jetlison/Release  Remote  Interface  Unit  -  Two  J/R  RIUs  provide  redundant  stores 
separation  capability  at  stations  3,  4,  5,  6  and  7.  Physically  located  on  separate  wings,  the  left 
and  right  J/’R  RIUs  are  identical  in  both  function  and  structure.  Each  RIU  interfaces  with 
Weapons  Mult^x  Bus,  the  Master  Arm  and  Release  Matrix  Assembly,  and  store  stations  3 
through  7.  The  J/R  RIUs  functk>n  as  (figitai  switches.  At  the  receifX  of  the  proper  release  code, 
the  J/R  RIU  will  dose  the  addressed  station  relay(s)  and  enable  ttie  J/R  Master  Arm  &  Release 
Power  to  energize  (ie,  enable  Fire  Cartridge  Command  rfiscrete)  the  cartridge  relay(s)  in  the 
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pylon(s).  This  enables  (he  firing  of  both  cartridges  in  each  MAU-12  pylon  bomb  rack.  The 
energy  released  from  firing  either  of  these  cartridges  is  sufficient  to  jettison  all  stores  on  the 
MAU'12.  In  additicn,  the  firing  of  one  cartridge  will  cause  the  sympathetic  firing  of  the  other. 
Therefoie,  only  one  J/R  RIU  needs  to  be  functional  to  perform  the  release  function.  The 
switching  logic  which  implements  these  functions  is  similar  to  that  of  Ihe  ACRIU.  One  J/R  RIU  is 
located  in  the  wing  area  immediately  behind  the  leading  edge  in  the  midsection  of  each  wing. 
Access  to  a  J/R  RIU  requires  the  removal  of  a  wing  surface  panel  on  the  leading  edge  which  is  a 
tedious  process.  The  aircraft  manufacturer  considers  the  J/R  RIUs  to  be  "permanently” 
installed. 

6.2.4. 1.6  Weapons  Multiplex  Bus  -  The  W-MUX  Bus  (or  Stores  Management  Mux  Bus)  provides 
(he  serial  digital  data  link  between  the  ACIU  and  the  RIUs  and  the  ACIU  and  the  stores.  A 
functional  diagram  of  this  data  link  is  presented  in  Figure  6.6.  The  ACIU  acts  as  Bus  Controller 
and  is  capable  of  driving  the  four  wire  (eight  wire  for  dual  redundant)  using  MIL-STD-1553, 
1553B  or  RIU  MUX  (dual  simplex)  protocols.  Eight  wires  (four  twisted  shielded  wire  pairs) 
are  provided  by  the  ACIU  to  communicate  to  the  RIUs.  These  eight  wires  are  connected  to  thirteen 
RIUs  via  seven  station  matrices.  Along  with  the  eight  transmission  lines  originating  in  the 
matrices  (for  redundant  dual-simplex  operation),  four  additional  wires  are  routed  to  the 
AMRIUs  and  the  ACRIUs  in  (he  form  of  two  twisted  shielded  wire  pairs.  Currently  these  wires 
are  terminated  in  the  following  disconnects:  wing  pylon  disconnect  (J812)  at  stations  3,  4,  6 
and  7;  wing  launcher  disconnect  (J810)  at  stations  1  and  9;  wing  adapter  disconnect  (J811)  at 
stations  1 .  3A,  7A  and  8;  and  aircraft  pylons  disconnect  (J237)  at  station  5.  These  wire  pairs 
provide  for  redundant  1 553/1 553B  operation. 

6. 2.4.1 .7  MIL-STn-1553  Capability  -  Bus  Controllers  in  the  ACIU  support  three  data 
transmission  protocols;  1553,  1553B  and  W-MUX.  There  are,  however,  no  1553  remote 
terminals  currently  in  the  RIUs  The  connection  which  links  the  1553  compatible  store  to  the 
Weapons  MUX  Bus  consists  of  two  twisted  shielded  wire  pairs  (to  provide  dual  redundancy). 
These  four  links  are  coupled  to  four  lines  of  primary  dual-simplex  bus.  This  coupling  is 
accomplished  at  the  station  mafices.  For  stations  without  a  1553  store,  these  coupled  lines 
terminate  at  the  wing  connector.  Additional  MIL-STD-15S3  capability  is  provided  to  store 
station  3,  4,  6  and  7  by  bringing  the  A-MUX  transmission  lines  to  the  aircraft-store  interface. 

6.2.4. 1.8  SMS  Software  •  The  SMS  Operational  Flight  Program  (OFP)  is  a  real-time  computer 
program  which  controls  the  selection,  monitoring,  conditioning,  and  release  of  stores  on  the 
F-16  C/D.  The  SMS  Cr  P  also  maintains  store  inventory  and  performs  certain  ancillary 
functions,  most  of  which  are  designed  to  provide  backup  system  control  in  the  event  of  a  Fire 
Control  Computer  (FCC)  failure.  Designed  to  operate  in  a  dual  processor  environment,  two 
structualiy  identical  copies  of  the  SMS  OFP  are  provided  to  the  ACiU.  With  one  copy  located 
within  the  primary  processor  and  other  within  the  backup  processor,  information  is  shared 
between  the  two  programs  via  dual-ported  RAM.  In  the  event  of  a  primary  processor  failure,  the 
backup  processor  will  assume  control  of  the  SMS  using  the  second  copy  of  the  SMS  OFP  and  the 
data  in  RAM.  Execution  of  the  SMS  OFP  is  accomplished  such  that  tasks  which  require  definite 
processing  rates  are  run  as  groups  at  periodic  rales.  Tasks  which  do  not  require  a  defined 
processing  rate  are  run  in  the  remaining  time  available  between  rale  groups.  The  SMS  OFP  is 
composed  of  the  14  components  described  below.  These  components  can  be  grouped  into  the 
following  three  categories:  operatirig  system  components,  applications  components,  and  support 
components.  The  operating  system  components  interface  the  application  tasks  within  the 
hardware.  Applications  components  perform  the  operational  functions  of  the  OFP.  The  support 
components  handle  the  ancillary  tasks  which  are  mostly  transparent  to  the  funclional  operation 
of  the  OFP,  but  which  are  necessaiy  in  order  for  those  functions  to  be  implemented.  An  example 
of  such  a  task  would  maintanance  of  queues.  Figure  6.7  illustrates  the  organization  of  these 
14  components  into  these  three  categories. 
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OPERATING  SYSTEM 


FIGURE  6.7  SMS  OFP  Struciure 
a  QpefatiDfl  System  Components 

( 1  )  Executive  Compo.ient  -  The  Executive  component  schedules  the  execution  of 
application  tasks  and  services  interrupts  and  other  computer-hardware  related  functions.  This 
component  provides  the  primary  interface  between  the  application  components,  the 
input/output,  timing  clocks,  and  error  checking  provisions  of  the  computer  hardware.  It  also 
coordinates  the  operation  of  the  Backup  Processing  component.  The  Executive  maintains  control 
unless  a  system  error  condition  is  detected  which  prevents  continuation  of  system  operation.  If 
such  an  error  condition  occurs,  control  is  returned  to  the  Error  Handling  component. 

( 2 )  The  Initialization  Component  -  After  a  power-on  interrupt  occurs,  the 
proper  initialization  (and  testing,  if  not  in  the  emergency  jettison  mode)  of  both  system 
hardware  and  software  is  performed  by  the  Initialization  Component.  Proper  operation  of  both 
processors  is  assured  with  a  full  range  of  ACIU  tests.  The  ACIU  master  processor  is  initially 
selected  during  initialization,  the  synchronization  of  the  A  and  B  processor  operation  is  achieved 
using  the  intercomputer  interrupt  in  a  command/response  arrangement,  and  both  system 
executives  are  initiated  by  the  Initialization  Component. 
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(  3 )  Error  Handling  Component  -  The  Error  Handling  component  detects  failure 
indication  from  the  power-down  interrupt,  the  machine  error  interrupt,  and  Test  component, 
the  Executive  component,  and  the  Initialization  component.  Upon  detection.  Error  Handling 
performs  fault  filtering,  isolation,  reporting,  recording  and  recovery  as  required  by  the 
particular  fault. 

(  4  )  Interface  Control  Component  •  The  Interface  Control  component  supervises 
the  input-output  via  the  serial  digital  multiplex  buses,  the  discrete  signals,  and  the  analog 
signals. 

b.  Support  Comtjonents 

( 1 )  Utilities  Component  -  This  component  provides  common  utility  and  testing 
routines  for  shared  use  by  the  other  components. 

(  2 )  Test  Component  -  The  test  component  conducts  self-test  and  built-in-test  on 
the  SMS  system.  Self-test  involves  continuous,  non-interruptive  testing  conducted  during 
normal  system  operations.  Built-in  test  is  operator  initiated  and  is  performed  interruptively 
or  during  normal  system  operation.  Self-test  is  conducted  on  the  non-volatile  memory,  the 
Remote  Intenace  Unit  (RIU)  communications,  the  weapons  bus  controller,  and  the  discrete 
input/output  boards.  Built-in  tests  are  conducted  on  RIUs  and  input  discretes.  Other  CIU 
elements  are  checked  with  hardware  self-test  features. 

( 3 )  Data  Transfer  Component  -  The  Data  Transfer  component  provides  double 
buffering  input/output  service  for  all  multiplex  data  flow  between  avionics  subsystems  and  the 
Stores  Management  Set  Operational  Flight  Program.  Additional  tasks  performed  by  this 
component  include  formatting  discretes  and  building  the  weapons  multiplex  bus  controller's 
command  table. 

( 4 )  System  Control  Component  •  The  System  Control  component  uses  the  SMS 
mode,  switch  positions,  and  other  indications  to  determine  the  tasks  to  be  executed.  This 
component  then  invokes  appropriate  subroutine  linkages  to  implement  the  selected  mode. 

c.  Applications  Components 

( 1  )  Stores  Accounting  Component  -  The  Stores  Accounting  component  accepts  and 
records  store  quantities,  types  and  locations.  This  component  updates  the  current  stores  based  on 
inputs  from  the  Stores  Release  component  or  operator  intervention.  This  component  also 
provides  the  appropriate  indication  of  the  discrepancies  between  the  operator  entries  and  the 
allowed  stores  configuration. 

( 2  )  Stores  Selection  Component  •  The  Stores  Selection  component  provides  the 
selection  for  display  and  release  of  stores  and  stations  in  the  emergency  jettison,  selective 
jettison,  dogfight,  missile  override,  air-to-a'r  rir-»o-ground,  and  gun  modes. 

( 3 )  Stores  Conditioning  and  Monitorino  Component  -  The  Stores  Conditioning  and 
Monitoring  component  provides  the  conditioning  and  monitoring  of  conventional  weapons,  special 
weapons,  and  RIUs.  This  component  also  provides  the  states  of  the  weapons  for  display. 

( 4 )  Stores  Release  Component  -  The  Stores  Release  component  performs  actions 
required  to  emergency  jettison  stores  on  stations  3  through  7,  selectively  jettison  all 
appropriately  selected  stores,  execute  manual  and  automatic  weapon  releases,  and  maintain  the 
gun  status. 
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(  5 )  Weapon  Deliverv  Mode  CQmtx)nent  -  The  Weapon  Delivery  Mode  component 
determines  the  current  system  master  mode  and  Stores  Management  Set  subsystem  mode.  This 
component  determines  the  Fire  Control  Radar  mode,  the  currently  selected  gun  arming  option  and 
weapon  delivery  profile. 

(  6 )  The  Backup  Processing  Component  -  The  Backup  Processing  component 
assumes  responsibility  for  tasks  normally  performed  by  the  FCC  when  the  FCC  is  incapable  of 
performing  them.  Only  tasks  which  provide  essential  self-defense  and  return-to-base 
capabilities  are  performed  by  the  SMS.  These  tasks  include  monitoring  the  display  management 
switch  to  determine  display  selection,  calculating  reference  altitude  settings,  providing  source 
control  of  the  slew  excitation,  maintaining  track  assignments  for  target  selections,  and 
determining  status  of  the  subsystems  pointer  to  command  the  FCH  to  enable  the  acquisition 
cursor. 

6.2.4. 1.9  Launcher  Electronics  -  This  paragraph  describes  the  functional  characteristics  of  the 
units  which  compose  the  launcher  electronics.  These  units  include  the  Launcher  Power  Supply, 
Aeriai  Ckimbat  Maneuvering  Instrumentation  (ACMI)  Pod  Relay,  and  safety  switch. 

a  Launcher  Power  Supply  -  The  Launcher  Power  Supply  provides  the  missile  with 
power  and  conditioning  signals.  By  rectifying  aircraft  supplied  115  VAC,  the  Launcher  Power 
Supply  provides  both  25.2  VDC  and  175  VDC  to  the  missile.  As  for  the  control  signals,  they  are 
sourced  by  commands  from  the  AMRIU.  Unlike  other  store  interface  units,  the  Launcher  Power 
Supply  has  no  direct  data  link  to  the  ACIU.  Other  functions  performed  by  the  Launcher  Power 
Supply  include  the  amplification  of  the  missile  audio  signal. 

b.  AMCI  Pod  Relay  -  The  ACMI  Pod  Relay,  located  in  the  missile  launcher,  controls  the 
audio  signal  to  the  intercom  system.  Sourced  by  a  discrete  from  the  ACMI  Pod,  the  relay  connects 
either  the  missile  audio  or  the  ACMI  Pod  Audio  to  the  intercom  system. 

C.  Safety  Switch  •  A  Safety  Switch  outputs  GAS  GRAIN  SQUIB  to  the  missile  and  FIRE  to 
the  AFT  Strike  Point  in  the  event  that  these  signals  are  activated  and  the  switch  is  enabled. 

6.2.4.2  Stores  Standby  Power  System  •  The  Stores  Standby  Power  System,  (Figure  6.8) 
provides  a  1 15  VAC  and  28  VDC  power  to  all  nine  store  stations.  Power  is  provided  to  the  Stores 
Standby  Power  System  via  the  aircraft  power  buses.  Control  is  accomplished  using  ACIU 
controlled  relays  located  in  the  Stores  Standby  Power  Matrices  (left  half,  LH,  and  right  half, 

RH).  arid  the  Nacelle  Equipment  Bay  Power  Panel.  Additional  relays,  located  in  the  Overcurrent 
Protection  Panel,  provide  overcurrent  protection  for  the  three  phase  115  VAC  at  stations  3,  5 
and  7.  The  components  of  the  Stores  Standby  Power  System  are  listed  below. 

Right  Strake  DC  Power  Panel 
Right  Strake  AC  Power  Panel 
Stores  Standby  Power  Matrix-RH 
Stores  Standby  Power  Matrix-LH 
Nacolle  Equipment  Bay  AC/DC  Power  Panel 
Overcurrent  Protectiori  Panel  No.  1 

6.2.4.2.1  Operation  -  Activation  of  the  Control  Ground  discrete  and  any  station  (1-9)  by  the 
ACIU  will  energize  the  DC  power  relay  in  the  Power  Matrix,  providing  28  VDC  at  the  store 
station.  For  stations  6,  7,  7A,  and  9,  these  DC  power  relays  are  located  in  the  right  half  (RH)  of 
the  Stores  Standby  Power  Matrix.  The  DC  power  relays  for  the  rest  of  the  stations  (stations  1 
2,  3,  3A,  4  and  5)  are  located  in  the  left  half  (LH)  of  the  Power  Matrix.  Control  of  the  station’ 
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AC  /  DC  POWER  PANEL.  NACELLE  EQUIPMENT  BAY 


FIGURE  6.8  Stores  Standby  Power  System 
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AC  power  is  accomplished  in  the  same  manner  as  the  DC  power  with  the  exceptions  of  stations  3, 

5  and  7.  Like  DC,  the  AC  power  at  stations  1.  2,  3A,  4,  6,  7A,  8  and  9  is  directly  controlled  by 
an  ACIU  enabled  ground.  For  stations  1.  2,  3A.  7A,  8  and  9,  these  ACIU  controlled  relays  are 
located  in  the  Nacelle  Equipment  Bay  Power  Panel.  The  Stores  Standby  Power  Matrix-RH 
contains  the  ACIU  controlled  relays  for  the  AC  signals  at  station  6.  and  to  the  Stores  Standby 
Power  Matrix-LH  containing  the  station  7  ACIU  controlled  AC  relays.  However,  the  AC  power  at 
stations  3,  5  and  7  are  not  directly  activated  by  a  control  ground  from  the  ACIU.  Instead,  they 
are  activated  by  a  discrete  which  results  from  the  ACIU  control  ground  closing  the  station  DC 
power  relay  on  the  overcurrent  signal  in  the  Stores  Standby  Power  Matrix.  The  resulting 
signal.  POWER  ON  CMD,  is  sent  to  Overcurrent  Protection  Panel  No.  1 ,  enabling  AC  power  to  the 
Store  Station. 

6.2.4.2.2  Functional  Description  •  All  components  of  the  Stores  Standby  Power  System  are 
considered  part  of  the  Avionics  Systems  Affected  (ASA)  by  the  implementation  of 
MIL-STD-1760.  The  functional  characteristics  of  these  components  are  given  in  following 
paragraphs. 

a  Right  Strake  DC  Power  Panel  -  The  Right  Strake  DC  Power  Panel  provides  the  DC 
power  for  all  nine  store  stations  (including  stations  3A  and  7A).  Power  is  taken  off  two  28  VDC 
buses  (ESS  &  BATT)  at  the  Right  Strake  DC  Power  Panel  and  routed  to  the  Stores  Standby  Power 
Matrices  (LH  and  RH).  At  the  Stores  Standby  Power  Matrices  the  power  is  switched,  by  ACIU 
controlled  relays,  between  open  and  the  store  stations. 

b.  Right  Strake  AC  Power  Panel  •  The  Right  Strake  AC  Power  Pane!  provides  three  phase 
1 1 5  VAC  power  for  stations  4  and  6.  Power  is  tedren  off  the  115  VAC  Main  Bus  at  the  Right 
Strake  AC  Power  Panel  and  routed  to  the  Stores  Standby  Power  Matrices  (LH  and  RH).  At  the 
Stores  Standby  Power  Matrices  the  power  is  switched,  by  ACIU  controlled  relays,  between  open 
and  the  store  stations. 

c.  Stores  Standby  Power  Matrix-RH  -  The  Stores  Standby  Power  Matrix-RH  is 
responsible  for  switching  the  28  VDC  power  at  stations  6,  7,  8  and  9,  providing  and  switching 
the  three  phase  115  VAC  power  at  station  6,  and  providing  the  station  7  power  control  signals 
(TRIP  ENABLE  and  POWER  ON  COMMAND)  to  Overcurrent  Protection  Panel  No.  1 .  All  switching 
in  the  Stores  Standby  Power  Matrix-RH  is  controlled  by  the  ACIU  via  control  ground  discretes 
(STANDBY  ARM). 

d.  Stores  Standby  Power  Matrk-LH  •  The  Stores  Standby  Power  Matrix- LH  is 
responsible  for  switching  the  28  VDC  power  to  stations  1,  2,  3,  3A,  4  and  5,  providing  and 
switching  the  three  phase  115  VAC  power  at  station  4,  and  providing  the  station  3  power  control 
signals  (TRIP  ENABLE  and  POWER  ON  COMMAND)  to  Overcurrent  Protection  Panel  No.  1 .  All 
switching  in  the  Stores  Standby  Power  Matrix-LH  is  controlled  by  the  ACIU  via  control  ground 
discretes  (STANDBY  ARM). 

e.  Nacelle  Equipment  AC/DC  Power  Panel  -  The  Nacelle  Equipment  AC/DC  Power  Panel 
is  responsible  for  providing  and  switching  the  three  phase  1 1 5  VAC  power  to  stations  1 ,  2,  3A, 
7A,  8  and  9.  This  panel  receives  power  from  the  115  VAC  ESS  and  non-ESS  buses,  switches  it 
via  ACIU  controlled  relays,  and  then  routes  it  directly  to  the  store  stations. 

f.  Qvercurrent  Protection  Panel  No.  1  -  The  Overcurrent  Protection  Panel  is 
responsible  for  monitoring  the  station  3,  5  and  7  control  signals  (TRIP  ENABLE  and  POWER  ON 
COMMAND)  and  providing  three  phase  115  VAC  power  to  those  stations  when  (1)  POWER  ON 
COMMAND  high,  (2)  TRIP  ENABLE  low,  and  (3)  the  115  VAC  current  to  the  store  station  does  not 
exceed  some  preset  bound. 
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6.2.4.3  Video  Switch  System  -  The  video  switch  (figure  6.9)  is  a  reconfigurable  network  (via 
switches)  designed  to  link  the  video  signal  sourced  at  a  store  to  the  display  equipment  in  the 
cockpit  or  to  other  stores.  These  stores  include  any  video  weapon  or  pod  mounted  at  stations  1-9 
(including  3A  and  7A),  the  Navigation  Pod  mounted  on  the  Right  Hard  Point  (RHP),  and  the 
Targeting  Pod  at  the  Left  Hard  Point  (LHP).  Acting  only  as  a  sink,  the  display  equipment  includes 
the  Programmable  Display  Generator  (PDG)  which  is  the  video  signal  processor  of  the 
Multifunctional  Display  Set  (MFDS),  and  the  Head-Up  Display  (HUD).  All  switching  in  the  video 
switch  is  controlled  by  discretes  from  the  ACRIU  and  the  DEEU  (Data  Entry  Electronic  Unit). 

6.2.4.3.1  Functional  Description  -  The  video  switch  consists  of  three  buses  (RHP,  LHP  and 
PDG),  nine  ACRIU  controlled  switches,  one  ACIU  controlled  switch,  and  three  DEEU  controlled 
switches.  The  nine  ACRIU  controlled  switches  are  responsible  for  switching  the  store  video 
signals  from  store  stations  1-9.  As  illustrated  in  figure  6.10,  the  ACRIU  uses  two  discretes  (Sel 
Video  A,  Sel  Video  B)  to  toggle  the  store  video  signal  switch  between  the  following  four  states:  (i) 
off.  (2)  LHP  Bus.  (3)  RHP  Bus.  and  (4)  PDG  Bus.  The  ACIU  controlled  switch  is  responsible  for 
linking  the  RHP  (Target  Pod)  with  the  RHP  Bus.  Using  one  disaete  (Sel  Video  RHP),  the  ACIU 
enables  and  disables  the  video  link  between  the  RHP  bus  and  the  RHP  (Target  Pod).  The  DEEU 
controlled  switch  to  the  RHP  (Target  Pod),  these  two  mutually  exclusive  states  are:  (1)  HUD. 
and  (2)  PDG.  At  the  LHP  (Navigation  Pod),  one  switch  connects  the  LHP  to  the  LHP  Bus  or  the 
HUD,  and  the  other  switch  links  the  LHP  to  the  PDG  or  LHP  Bus.  Elements  of  the  Video  Switch  are 
described  below; 

a  Left  Wino  Video  Switch  -  The  Left  Wing  Video  Switch  houses  the  store  video  switches 
for  stations  1,  2,  3,  3A  and  4.  Controlling  these  switches  are  five  pairs  of  discretes  from  the 
corresponding  station  RIUs.  Depending  upon  the  state  (that  is,  open  or  ground)  of  these  two 
discretes,  the  store  video  switch  will  connect  the  store  video  to  one  of  the  following:  (1)  Open, 
(2)  PDG  Bus,  (3)  LHP  Bus,  or  (4)  RHP  Bus.  Figure  6.11  illustrates  this  switching  scheme. 

b.  Right  Wing  Video  Switch  -  The  Right  Wing  Video  Switch  houses  the  store  video 
switches  for  stations  6,  7,  7A,  8  and  9.  Controlling  these  switches  are  five  pairs  of  discretes 
from  the  corresponding  RIUs.  Depending  upon  the  state  of  these  two  discretes,  the  store  video 
switch  will  connect  the  store  video  to  one  of  the  following:  (1)  Open,  (2)  PDG  Bus,  (3)  LHP  Bus, 
or  (4)  RHP  Bus. 

c.  Central  Video  Switch  -  The  Central  Video  Switch  houses  the  station  5  ACRIU  controlled 
store  video  switch,  the  ACIU  controlled  RHP  video  switch,  and  the  DEEU  controlled  RHP/HUD, 
LHP/HUD  and  LHP/PDG  switches.  The  station  5  store  video  switch  provides  station  5  video  to  the 
LHP.  RHP,  and  PDG  buses  by  the  same  control  process  described  above  for  the  other  switches. 

The  LHP  video  switch  toggles  the  Target  Pod  video  between  the  HUD  and  RDG.  Control  of  this 
switch  is  provided  by  the  DEEU  enabled  discrete  LHP/HUD  VIDEO  SELECT.  The  other  two  DEEU 
enabled  switches  control  the  distribb  .or  v  he  Navigational  Pod  Video.  The  RHP/HUD  switch 
toggles  NAVIGATION  POD  VIDEO  betw  ?e  ^  HUD  and  the  RHP  Bus.  and  the  RHP/HUD  switch  links 

NAVIGATION  POD  VIDEO  to  either  the  r.  JL. ..  RHP  Bus. 

d.  PDG  Bus  -  The  PDG  Bus  p'c  oes  a  video  link  from  all  of  the  store  video  switches 
(located  in  the  Left  Wing.  Right  v;irk..  and  :;entrai  Video  Switches)  to  the  PDG. 

e.  LHP  Bus  -  The  LHP  Bus  provides  a  video  link  from  all  of  the  store  video  switches 
(located  in  the  Left  Wing.  Right  Wing,  and  Central  Video  Switches)  to  LHP/HUD  and  LHP/PDG 
switches  in  the  Central  Video  Switch.  As  illustrated  in  figure  6.11,  the  LHP  Bus  can 
accommodate  store-to-store  video. 
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FIGURE  6.9  Video  Switch  Functional  Diagram 


67 


f.  RHP  Bus  -  The  RHP  Bus  provides  a  video  link  from  all  of  the  store  video  switches 
(located  in  the  Left  Wing.  Right  Wing,  and  Central  Video  Switches)  to  the  RHP  video  switch  in  the 
Central  Video  Switch.  Like  the  LHP  Bus.  the  RHP  Bus  can  also  accommodate  store-to-store  video. 

6.2.4.3.2  Block  25  Configuration  •  The  Block  25  F-16  C/D  only  partially  utilizes  the  capacity 
of  the  Video  Switch.  Stations  3,  4.  6  and  7  (Maverick  Certified  Stations)  are  the  only  switches 
which  are  fully  video  capable.  As  for  the  other  stations,  the  air-to-air  stations  have  wiring 
provisions  for  video,  but  station  5  (the  centreline  station)  does  not.  Stations  2,  3A,  7A,  and  8 
have  a  video  line  and  the  two  video  control  lines  (SEL  VIDEO  A  &  SEL  VIDEO  B)  out  to  the 
adapter/launcher  disconnect.  At  the  Wingtip  air-to-air  stations,  stations  1  and  9,  three  lines 
terminate  at  the  wing/launcher  disconnect.  A  summary  of  the  video  switch  functions  in  Block  25 
aircraft  is  as  follows: 


Weapon  Video  from  stations  4.  5,  6,  or  7  to  the  MFDS 

Navigation  Pod  Video  from  the  RHP  to  the  MFDS 

Target  Pod  Video  from  the  LHP  to  the  MFDS 

Navigation  Pod  Video  from  the  RHP  to  the  HUD 

Target  Pod  Video  from  the  LHP  to  the  HUD 

IR  Maverick  Video  from  stations  4.  5,  6.  7  to  the  Target  Pod 

Note  that  these  operational  configurations  of  the  Video  Switch  are  a  function  of  both  the  partial 
implementations  of  the  switch  in  the  F-16  C/D  and  current  store  requirements. 


FIGURE  6.10  F-16  Video  Control 
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POO  BUS 


FIGURE  6.11  F-1 6  Video  System 
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CTATION  1  <•)  11  STATION  2  (dIIsTATION  J  (T)  or  SA  (7A)  1 1  STATION  4  <•)  M  STATION 


6.3  IMPLEMENTATION  REQUIREMENTS  Two  overall  requirements  imposed  on  the  1760 
Implementation  Case  Study  which  particularly  influenced  the  study  results  were:  to  make 
maximum  use  of  existing  equipment,  and  accommodate  both  the  current  and  future  stores  defined 
for  the  F-16  C/D.  The  first  requirement  forces  a  designer  to  augment  the  existing  aircraft 
configuration  with  a  1760  capability  rather  than  develop  a  new  independent  approach.  The 
second  requirement  necessitated  a  dual  cap^lity  at  each  store  station.  This  resulted  in  a 
number  of  engineering  compromises.  From  a  comprehensive  review  of  the  store  loadouts  and 
associated  control  requirements  presented  in  paragraph  6.2.2,  it  was  determined  that  a  Class  lA 
interface  was  required  at  stations  3,  5.  and  7,  a  Class  I  interface  at  stations  4  and  6,  and  a  Class 
II  interface  at  the  air-to-air  stations.  The  major  system  modifications  found  to  be  required  to 
implement  the  desired  capabilities  are  listed  below: 

a  Provide  redundant  MIL-STD-1553  digital  buses  to  the  ASIs  at  the  air-to-air  stations 

b.  Provide  two  RF  lines  (HB1  and  HB2)  to  the  ASI  at  each  air-to-ground  station  and  one 
RF  line  (HBI)  to  the  ASl  at  each  air-to-air  station 

c.  Provide  a  second  video  line  to  the  ASIs  at  stations  4.  5.  and  6 

d.  Provide  a  single  video  line  to  the  ASIs  at  the  air-to-air  stations 

e.  Provide  the  second  and  third  phases  of  the  115  VAC  to  the  ASIs  at  the  air-to-air 
stations 

f.  Provide  a  second  28  V,  10  A  DC  source  to  all  ASIs  (total  of  20  A/station) 

g.  Provide  independent  AC  and  DC  power  control  to  all  ASIs 

h.  Provide  28  VOC  auxiliary  power  to  the  ASIs  at  stations  3,  5,  and  7 

i .  Provide  1 760  compatible  signals  currently  routed  to  the  existing  ASIs  to  each  1 760 
interface  as  required 

j .  Physically  locate  the  primary  and  auxiliary  1760  connectors  at  the  station  3,  5.  and 
7  ASIs;  and  the  primary  connector  at  all  other  ASIs 

k.  Provide  the  additional  ACIU  software  to  control  MIL-STD-1760  stores  and  to 
implement  the  changes  in  the  Operational  Flight  Program  required  by  the  suggested  modifications 

l .  Provide  additional  ACIU  hardware  to  support  the  extra  processing  load  and  modified 
MIL-STO-1553  hardware 

6.3.1  Discussion  of  Required  Modifications.  The  following  paragraphs  provide  an  approach  to 
the  implementation  of  a  MIL-STO-1760  capability  in  the  case  study  aircraft,  which  fulfill  the 
twelve  requirements  defined  above  in  paragraph  6.3.  In  consonance  with  design  constraints, 
current  and  planned  MIL-STD-1760  provisions  by  the  F-16  prime  contractor  were  used  to  the 
maximum  extent  possible.  Figure  6.12  shows  the  configuration  of  MIL-STD-1760  interface 
classes  which  will  be  implemented  at  each  of  the  P-16  weapon  stations  in  this  case  study. 
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FIGURE  6.12  F-16  Case  Study  Configuratkvn  of  MIL-STD-1760  Interface  Classes 


6.3.1. 1  Modification  #1:  Provide  Redundant  MIL-STO-1553  Digital  Buses  to  the  Aircraft 
Station  Interface  (ASI)  at  the  Air  to  Air  Stations  -  A  MIL-STD-1553  capability  could  be 
provided  by  either  extending  the  A-MUX  or  W-MUX  out  to  the  air-to-air  stations.  While  there 
are  advantages  to  extencAng  the  A-MUX,  particularty  relative  to  control  of  AMRAAM,  long-term 
considerations  favor  the  W-MUX.  The  W-MUX  in  the  F-16  C/D  is  a  four  wire  system  which 
currently  supports  three  communication  protocols,  including  MIL-STD-t553.  Therefore 
compliant  twisted-shielded  pairs  require  to  be  run  from  the  W-MUX  station  matrices,  through 
the  wing  pylon  disconnects,  out  to  the  respective  ASis  for  stations  1 ,  2.  3A.  7A,  8  and  S.  The 
1 553B  lines  have  already  been  taken  from  the  station  matrices  to  pylon  disconnects  for  the  air- 
to-ground  stations.  Figure  6.13  indicate  the  changes  (dashed  lines)  required  to  provide  1553B 
capability  to  the  air-to-air  ASIs.  It  should  be  noted  that  the  MUX  lines  in  the  Station  Matrix 
primarily  serve  as  two  of  the  four  lines  required  for  the  GD  dual  simple  W-MUX.  Any  analyses 
of  bus  utilization,  therefore,  will  have  to  include  current  W-MUX  traffic.  The  dual  simplex 
system  wM  continue  to  be  used  to  command  state  transitions  In  the  RIUs.  Two  other  points  are  of 
significance:  (1)  the  15536  lines  are  transformer  coupled  to  the  W-MUX  inside  of  the  Station 
Matrix  such  that  the  extension  to  the  ASI  is  a  legitimate  stub;  and  (2)  the  ACIU  Bus  Controller  is 
capable  of  dual  simplex,  GD  1553  and  15536  protocols  so  that  hardware  modifications,  other 
than  extemSng  the  sti^  to  the  ASI,  should  not  be  rec^ired. 

TABLE  6.1  Location  of  W-MUX  Station  Matrices 


71 


Some  potential  issues  associated  with  this  modification  include:  (1)  shortages  of  ACIU 
processing  power/memory;  (2)  software  (OFP)  modificationArerification  capabilities;  and  (3) 
availability  of  space  in  the  current  wing  disconnects  to  route  the  1553  buses. 
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FIGURE  b.13  Extension  of  1553  to  Stations  1.2,3A,7A,  8,  and  9 
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6.3.1 .2  Modiiication  #2:  Provide  Two  RF  Lines  (HB1  and  HB2)  at  the  Air-to-Ground  ASIs  and 
One  RF  Line  (HB1)  at  the  Air-to-Air  ASIs  •  MIL-STD-1 760A  requires  two  50-ohm  RF  lines 
(HBi,  20  MHi  -  1.6  GHz  and  HB2,  20  Hz  -  20  MHz)  for  Class  I  interfaces,  and  one  RF  line 
(HBi,  20  MHz  to  1.6  GHz)  for  class  2  interfaces.  These  cover  the  requirements  for  air  to 
ground  and  air  to  air  respectively  At  this  time,  eight  provisioning  RF  lines  are  in  the  F-16 
C/D.  These  I'nes  extend  from  the  aft  equipment  bay  to  the  wing  disconnects  at  stations  3.  4,  6 
and  7  (two  lines  per  station).  The  modifications  will  extend  these  eight  lines  from  the  wing 
disconnects  to  stations  3.  4.  6  and  7.  and  two  additional  50-ohm  lines  run  from  the  aft 
equipment  bay  to  the  ASI  at  station  5.  A  single  1.6  GHz,  50  ohm  line  would  run  from  the  aft 
equipment  bay  to  each  of  the  four  air-to-air  ASIs.  An  RF  switching  capability  would  be  installed 
in  (or  near)  the  aft  equipment  bay  to  provide  MIL-STD-1760  recommended  connectivity;  that  is 
a  simultaneous  transfer  of  one  Type  B  signal  and  two  Type  A  signals  between  ASIs  and  internal 
aircraft  equ'pmsnt.  plus  one  Type  A  signal  between  any  two  ASIs.  Switches  would  be  controlled 
by  discretes  generated  Icically  by  an  MT/Logic  Unit  added  to  the  W-MUX.  Figure  6.14  is  a 
functional  depiction  of  an  alternative  switching  network  for  providing  the  RF  connectivity 
recommended  by  MIL-STD-1760.  As  a  matter  of  fact,  it  will  provide  slightly  more  capability 
than  required  by  1760  in  that  it  indud-^s  the  option  of  a  third  simultaneous  50-ohm,  20  MHz 
connection  to  aircraft  subsystems.  This  switching  matrix  would  be  packaged  as  a  single  unit  and 
housed  in  the  aft  equipment  bay.  Running  from  the  switching  unit  would  be  two  50-ohm  lines  to 
each  air-to-ground  station  (HBi  and  HB2)  and  one  50-ohm  line  (HBi)  to  each  of  the  air-to-air 
stations.  Two  types  of  switches  are  requifaa  in  the  switching  unit.  This  is  because  of  differences 
in  the  electrical  characteristics  between  HBI  and  HB2.  Figure  6.15  illustrates  a  switch  which 
is  suitable  for  Type  A  (20  Hz  -  20  MHz)  signals.  As  indicated  in  the  figure,  HB2  lines  have 
access  to  three  internal  buses,  plus  a  characteristic  impedance  termination.  Two  discretes  are 
required,  therefore,  to  control  the  four  possible  states.  In  this  alternative,  these  discretes  are 
generated  by  the  station  RIU  in  response  to  a  CIU  command  on  the  W-MUX  -  in  a  manner 
analogous  to  the  way  video  switching  Is  currently  performed.  The  Type  B,  1.6  GHz  signal  lines 
cannot  be  treated  so  casually.  The  insertion  icos.  transmission  loss  and  fidelity  requirements  of 
this  signal  make  switching  much  more  difficult.  It  can  be  assumed,  however,  that  HBI  can  be 
effectively  switched  to  a  transmission  line  network  serving  Type  B  signal  users,  to  any  one  of  the 
three  networks  serving  Type  A  signal  users,  and  to  a  characteristic  impedance  termination  -  or 
five  states.  It  can  also  be  assumed,  then,  that  three  discretes  would  be  required  to  control  each 
h31  switch.  Under  this  alternative  these  discretes  would  be  provided  by  the  station  RIUs. 

Figure  b.l6  illustrates  the  wiring  changes  required  to  implement  this  central  switching  scheme. 
As  shown  in  this  figure,  it  requires  extending  the  two  provisionary  RF  lines  out  to  the  ASI  at 
stations  3.  4,  6,  and  7,  running  HBI  and  HB2  from  the  aft  equipment  oay  out  to  tne  ASI  at  the 
air-to-air  stations,  and  providing  the  four  HBW  lines  to  the  avionic  equipment.  This 
implementation  has  several  advantages:  (1)  switches  are  centrally  located  which  would  reduce 
installation  and  maintenance  costs:  (2)  switches  ca*.  be  consolidated  and  line  lengths  kept 
electi icni'y  short;  and  (3)  the  1.6  GHz  (HBi)  I'.tes  could  be  configured  to  enable  essentially 
point-to-point  transmissions,  alleviating  VSWR  and  unnecessary  insertion  lost  problems. 
Switching  is  controlled  in  this  design  by  c.scretes  generated  by  the  RIUs.  These  discretes  would 
be  generated  by  an  RT/Logic  unit  connected  to  the  V/  MUX.  The  entire  assembly  would  b;; 
physicnily  attached  to  the  switching  unit.  A  potential  disadvantage  is  'he  requirement  for 
physical  space  in  the  aft  equipment  bay  for  the  RT/Logiu  urn;  jnd  ’.he  reqiji.ement  for  a  r^edicated 
RT  1553  address.  Potential  issues  associated  with  implementatiori  of  this  resign  include: 

a  Availability  of  space  in  the  aft  equipment  bay  to  implement  the  switching  matrix 

b.  Availability  of  additional  discretes  (Five  each  from  the  CRIUs  and  three  each  from  the 
MFlUs) 
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MBI  LINES  TO  ALL  STATIONS 

FIGURE  6.14  Centralized  High  Bandwidth  Switching  Network 


c.  Availability  of  space  in  air-to-air  station  wing  disconnectors  for  the  additional 
discretes 

d  Availability  of  space  in  the  station  5  fuselage  disconnect  to  accommodate  the  three 
additional  discretes  and  two  additional  RF  lines 

e.  Rouhng  of  HBi  lines  and  discretes  from  the  air-to-air  stations  to  the  aft  equipment 
bay  may  require  deskinning  the  aircrah 

f.  Selection  criteria  for  switching  elements 

g  Technology  to  meet  1 760  1 .6  GHz  signal  transfer  requirements 
h.  OFP  Software  modihcaticiis 
i  Availability  of  RT  addresses 

] .  Network  costs;  particularly  for  seominqiy  unneeded  capability 


FIGURE  6.15  Digital  High  Band  Frequency  Switch 

An  alternative  to  the  selected  approach  which  was  rejected,  but  is  something  to  track,  is  to 
employ  Frequency  Division  Multiplexing  (FDM)  techniques.  This  alternative  would  be  to  install 
a  single  50  ohm  line  from  each  ASI  to  the  aft  equipment  bay  to  accommodate  the  1 .6  GHz  signals, 
along  with  a  FDM  to  provide  the  required  connectivity  for  the  20-MHz  lines.  The  FDM  scheme 
would  serve  as  a  medium  for  transmission  of  the  Type  A  signals  HB2,  HB3,  and  HB4.  HB1  would 
be  handled  as  in  Alternative  1 .  There  is  significant  work  being  done  in  this  area,  particularly  in 
conjunction  with  the  high  bandwidth/low  noise  possibilities  available  I  cm  fiber  optics.  It  is  not 
felt,  however,  that  this  technology  is  sufficiently  mature  to  be  a  viable  alternative  at  this  time. 

6.3. 1.3  Modification  #3:  Provide  a  Second  Video  Line  to  the  ASIs  at  Stations  4,  5,  and  6  -  To 
satisfy  the  requirements  of  a  MIL-STD-1760A  Class  I  interface,  two  75-ohm,  20  MHz  (HB3, 
HB4)  lines  must  be  provided  at  an  Air-to-Qround  ASI.  The  currently  planned  F-16  C/D  1760 
configuration  provides  these  two  lines  at  stations  3  and  7,  but  only  a  single  line  at  stations  4,  5 
and  6.  This  modification  carries  existing  provisions  to  the  ASI  and  adds  the  additional  lines  to 
stations  4,  5,  and  6.  Video  lines  would  be  run  from  the  station  4  ASI  to  the  Right  Video  Switch, 
the  station  5  ASI  to  ihe  Central  Video  Switch,  and  from  the  station  6  ASI  to  the  Central  Video 
Switch.  Control  would  be  provided  by  discretes  generated  by  he  RT/Logic  unit  added  to  the  W- 
MUX.  One  additional  relay  would  be  added  to  each  switch  matrix.  Figure  6.17  illustrates  the 
implementation  of  the  additional  video  line  at  stations  4,  5,  and  6.  in  addition  to  the  indicated 
video  lines  and  control  discretes,  one  switching  element  would  also  have  to  be  installed  in  each  of 
the  existing  three  video  switches  (Right,  Left,  Central).  Figure  6.18  illustrates  this  video 
switching  unit.  The  discretes  to  switch  both  tiie  added  and  existing  video  lines  would  be  generated 
by  an  RT/Logic  unit  on  the  W-MUX,  possibly  Ihe  same  unit  providing  discretes  for  switching  the 
RF  lines.  This  approach  is  illustrated  in  figure  6.19  and  was  previously  identified  in  the 
discussion  of  Modification  6.3. 1.2.  The  advantage  of  this  approach  is  that  it  is  adaptable  to  future 
growth  and  eliminates  the  requirement  for  new  (and  some  existing)  discretes  from  station  RIUs. 
The  disadvantage  is  that  modifications  are  being  made  to  existing  flight-qualified  hardware  and 
software.  This  could  be  difficult  to  justify,  but  the  alternative  of  control  being  provided 
partially  from  station  RIUs  and  partially  from  the  added  RT/Logic  unit  would  be  unacceptable. 
The  major  issues  (associated  with  this  approach)  are  availability  of  space  for  routing  the 
control  discretes  from  the  RT/Logic  Unit  (probably  in  the  aft  equipment  bay)  to  the  Left,  R^hi 
and  Central  switching  units,  and  availability  of  an  RT  address.  Other  issues  include: 
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FIGURE  6.16  Proposed  F-1S  C/D  Rr' Network 


T  « 


NOTES:  (t)  J34a  -  FLAT  PIN  RF  CONNECTOR.  CURRENUV  FI 
(2)  JSSa  •  FLAT  PM  RF  CONNECTOR,  CURRENTLY 


a  OFP  modifications 


b.  Bandwidth  of  existing  video  lines,  that  is  can  they  meet  the  requirements  of  H63  and 

HB4 


c.  Space  to  route  the  additional  video  lines  and  control  discretes  through  the 
pylons,  the  wing  disconnects 

d.  Compatibility  of  1760,  75-ohm  system  with  the  current  F-16,  96-ohm 
video  system 


e.  Definition  of  existing  video  system 

STATION  4  STATION  4 

WING  DISCONNECT  1760  ASI 


LEFT 

VIDEO 

SWITCH 


STATION  4  VIDEO 


□ . □ 

JS12 


STATION  4  STATION  4 

STATION  4  VIDEO  WING  DISCONNECT  RIU 


_ _ 

STATION  4  VIDEO 
SEL  2 


□zdZI 

J610  J902 


STATION  S  STATION  S 

WING  DISCONNECT  1760  ASI 


_ _ 1 - 1 

CENTRAL 

V;DE0 

SWITCH 

STAflON  S  vYOEd 

1 _ 1 

STATION  5  VIDEO 

SEL  1 

STATION  5 
RIU 

STATION  5  VIDEO 

SEL  2 

:::0 

J299 

J902 

STATION  6  STATION  6 

WING  DISCONNECT  1760  ASI 


CENTRAL 

VIDEO 

SWITCH 


STATION  6  VIDEO 


a . n 


J612 

STATION  6 
STATION  6  VIDEO  WING  DISCONNECT 

. mj 

STATION  6  VIDEO 

. . 

J610 


STATION  6 
RIU 


J902 


FIGURE  6.17  Second  Vioeo  Ur.e  to  ST  As  4, 5.  and  6  1760  ASI«; 
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FIGURE  6.18  Functional  Representation  of  a  Video  Switching  Unit  (Element) 


WMUX 


STATION  4 
WINO 


DISCONNECT 

LEFT 

STATION  4 

VIDEO 

VIDEO  B 

SWITCH 

5TF5R 

4 

J«10 

ASI 


SEL  1 

set  2 


RT/ 

LOGIC 

UNIT 


SEL  1 
SEL  a 


PENTRAU 

VIDEO 

SWITCH 


STATION  S 

FUSELAGE  STATION  S 
DISCONNECT  ASI 


(STATION  $ 

vioIo'b 


SEL  1 
SEL  3 


RIGHT 

VIDEO 

SWITCH 


STATION  6 
ASI 


STATION  t 
vioio'B' 


STATION  6 
WING 

DISCONNECT 


Note:  Design  also  requires  one  additional  pair  of  discretes  between  the  WMUX  RT 
and  Central  Video  Switch  (STATION  5  VIDEO  A  SEL  1  &  2),  five  additional  discrete 
pairs  between  the  MUX  RT  and  Lett  Video  Switch  (STATION  1  VIDEO  SEL  1  &  2. 
STATION  2  VIDEO  SEL  1  &  2.  STATION  3  VIDEO  A  SEL  1  &  2.  STATION  3  VIDEO  B 
SEL  1  &  2.  STATION  4  VIDEO  SEL  1  &  2).  and  five  additional  pairs  of  discretes 
between  the  WMUX  RT  and  Right  Video  Switch  (STATION  9  VIDEO  SEL  1  &  2, 
STATION  8  VIDEO  SEL  1  &  2.  STATION  7  VIDEO  A  SEL  1  &  2,  STATION  7  VIDEO  B 
SEL  1  &  2,  STATION  6  VIDEO  SEL  1  &  2)  to  control  existing  video  lines. 


FIGURE  6.19  Video  to  Stations  4,  5,  and  6 
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6.3. 1.4  Modification  #4:  Provide  a  Single  Video  Line  to  the  ASIs  at  the  Air-to-Air  Stations  - 
This  modification  would  provide  the  required  video  capability  for  a  Class  II  Interface  at  stations 
1,  2,  3A,  7A,  8  and  9.  The  required  change  will  be  to  connect  a  75  ohm,  20  MHz  line  from  the 
video  switch  to  each  of  the  ASI.  This  is  a  simple  modification  which  extends  existing  video  lines 
to  the  1760  ASI.  Figure  6.20  functionally  illustrates  routing  of  these  video  provisions.  The 
existing  video  provisions  are  located  as  follows; 


STATION 


ECTOR  UOCATTON 


STA1 

J528 

STA2 

J528 

STA3A 

J521 

STA7A 

J621 

STAS 

J81  1 

STA9 

J628 

Left  wing  wiring  harness  (See  Note) 
Left  wing  wiring  harness 
Left  wing  wiring  harness 
Right  wing  wiring  harness 
Wing/Pylon  disconnect 
Right  wing  wiring  harness 


Note;  The  wing  wiring  harness  is  located  in  the  center  of  the  wing  behind  the  leading  edge  flap. 


STATION  «  STATION  1 

17«Q  ASI  WINQ  DISCONNECT 


1 - 

1  '  1  station  1 

1  1  VIDEO 

1 _ 1 

STATION  2 
17«0  ASI 

1 - 1- 

. 1 _ 1 . 

STATION  2 

WIND  DISCONNECT 

r— - 1  STATION  2 

I  1  VIDEO 

2 

1 _ 1 

. 1 _ f . 

J.tll  J.S2t 


STATION  SA 
1TW  ASI 


STATION  SA 
WIND  DISCONNECT 

. Q- 


station  ia 

VIDEO 


1 


TTTT 


STATION  7A 
17SO  ASI 


STATION  7A 
WING  DISCONNECT 

. n . 


STATION  7A 
VIDEO 


-nrr 


TTATION  9 
VIDEO 


I  STATION  S 

-.yjpAQ... 


j-ste 


station  9 
WIN3  DISCONNECT 


STATION  9 
1760  ASI 


station  9 
WINQ  DISCONNECT 


STATION  S 
17S0  A5I 


J.tll 


FIGURE  6.20  Routing  to  Stations  1.  2.  3A,  7 A,  8.  and  9  1760  ASIs 
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The  discretes  which  control  video  switching  would  be  provided  by  an  RT/Logic  unit  on  the 
W-MUX  Bus.  This  could,  but  would  not  have  to  be.  the  same  RT/Logic  unit  used  to  control  the  RF 
network.  The  existing  discrete  provisions  are  located  as  follows: 


STATION 

OOhrCCTOR 

LOCATION 

STA1 

J527A 

Left  wing  wiring  harness 

STA2 

J527A 

Left  wing  wiring  harness 

STA3A 

J519A 

Left  wing  wiring  harness 

STA7A 

J627A 

Right  wing  wiring  harness 

STAS 

J627A 

Right  wing  wiring  harness 

STAS 

J627A 

Right  wing  wiring  harness 

Figure  6.21  illustrates  the  routing  of  these  discretes.  The  advantages  to  this  alternative  are  that 
it  is  technically  simple  and  uses  existing  provisions  to  the  maximum  extent.  The  disadvantage, 
again,  is  that  an  existing,  certified  capability  will  have  to  be  abandoned  if  RF/Video  controls  are 
consolidated  and  care  will  have  to  be  taken  to  avoid  cross  talk  from  RF  to  Video.  Implementation 
issues  are  the  availability  of  space  to  implement  the  RT/Logic  Unit  and  to  route  the  appropriate 
discretes  to  the  video  switches,  the  difference  in  the  characteristic  impedance  of  the  current 
video  lines  (95  ohms),  and  the  MIL-STO-1760A  requirement  for  75  ohms,  20  MHz  lines. 


tlATIOM  1 

MMU 


STATIOM  2 
IMIU 


STAnON  1 
WIHO  CNSCONMCCT 


STATION  a 
WMO  OlOCONNECT 


STATION  lA 
MMU 


STATION  SA 
NINO  OISCONNSCT 


jfta  4ca7A 


AT10N  lA  V»SO  WL  t 
ISTATION  SA  VNSO  SEt  t 


STATION  /A  V10C0  SSt  af 


STATION  7A 
WINQ  OISCONNCCT 


STATION  7A 
MfSO 


STATION  7A  VMO  SSL  S 


STATION  S 
WINQ  DISCOHNSCT 


JStTA 


JS11 


STATION 
MNIU 


jssa 


4SI7A 


STATION  t 
WINS  OtSCONNCCT 


STATION  S 
MNIU 


FIGURE  6.21  Routing  of  Video  Switch  Discretes  to  Stationsi ,  2,  3A,  7A,  8,  and  9  MRIUs 
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6.3.1 .5  Modificatjon  #5:  Provide  the  Second  and  Third  Phases  of  115  VAC  to  the  ASIs  at  the 
Air-to-Air  Stations  -  Three  phase  AC  currently  extends  to  existing  connectors  near  each  store 
station.  For  the  air-to-air  stations,  however,  only  a  single  phase  is  carried  through  to  the  ASI. 
This  modification  would  provide  the  second  and  third  phases  by  running  the  two  wires,  currently 
terminated  in  a  provisioning  connector  within  the  aircraft,  out  to  the  station  ASIs  via  the  wing 
pylon  disconnect.  As  indicated  in  figure  6.22,  Modification  #5  requires  running  two  wires  (per 
station)  from  the  provisioning  connectors  listed  below  through  the  wing/pylon  disconnect 
connectors  (also  listed  below),  and  on  to  the  ASI.  The  provisioning  connectors  are  all  located 
within  the  wing  near  the  disconnects. 


Siatiflii 

Connector 

STA1 

J529 

STA2 

J530 

STA3A 

J522 

STA7A 

J622 

STA8 

J630 

STA9 

J629 

Wina-Pvlon  Connector 

J610 

J61 1 

J61 1 

J61 1 

J61 1 

J610 


Issues  associated  with  adding  the  115  VAC  power  phases  are  related  to  space  in  the  air-to-air 
wing-pylon  disconnect  connectors.  Another  potential  issue,  which  is  equally  associated  with  DC 
provisions,  is  virheiher  or  not  a  more  sophisticated  power  management  system  may  be  required  to 
prevent  overloading  existing  aircraft  circuits. 

STATION  1  STATION  1 

1TS4  ASI  WINO  DISCONNECT 

STANoet  AC  ec 
STANOev  AC  OS 


JS10  JSTS 

STATION  2  STATION  2 

STANDBT  AC  OA 
STANDOT  AC  9C 


JS11  .ISSO 

STATION  SA  STATION  SA 

iTsa  ASI  WING  osconnect 

STANDBY  AC  SB 
STANDBY  AC  BC 

Jfll  J$22 

STATION  TA  STATION  TA 

WING  DISCONNECT  17«0  ASI 

standby  AC  BA 
STANDBY  AC  B8 

Jtll  Jt22 

STATION  S  STATION  S 

WING  OnCONNCCT  17*0  ASI 


irso  ASI 


WINO  DISCONNECT 


JSSO  Jill 

STATION  S  STATION  S 

WING  DISCONNECT  I7W  ASI 


STANDBY  AC  BB 

1 

2 

JS2S 

STANDBY  AC  BC 

FIGURE  6.22  Routing  of  Second  and  Third  115  VAC  Phases  to  Stations  1 , 2.  3A,  7A,  8,  and  9 


6.3.1. 6  Modification  #6:  Provide  Second  28  VDC  10  A  Source  to  All  ASis  (total  of  20  A  per 
Station)  -  MIL-STD-1760  requires  two  independently  controlled  28  VDC  power  sources  at  each 
ASI  (total  of  20  amps).  The  current  aircraft  configuration  features  a  single  10-14  amp  source 
at  each  station.  There  is  an  indication,  however,  that  the  circuit  breaker  setting  is  an  arbitrary 
one  and  that  a  secornj  10-amp  28  VDC  source  could  be  provided  by  adding  another  line  and 
changing  the  circuit  breaker.  It  appears  from  a  review  of  available  information  that  the  total 
current  limitation  of  14.4  amps  at  the  air-to-ground  stations  and  10.8  amps  at  the  air-to-air 
stations  are  due  lo  circuit  breaker  limitations.  It  is  assumed,  therefore,  that  to  provide  the 
needed  20  A  of  28  VDC  to  1760  interfaces  simply  requires  implementing  higher  current  circuit 
breakers. 

6.3. 1.7  Modification  #7:  Provide  Independent  AC  and  DC  Power  Control  at  all  ASIs  -  Power  to 
ASIs  is  currently  applied  through  relays  in  the  Store  Standby  Power  Matrices.  Relays  are 
controlled  by  discretes  directly  from  the  ACIU.  AC  and  DC  are  applied  simultaneously.  Earlier 
modifications  would  provide  the  second  and  third  phases  of  AC  and  a  second  DC  source.  This 
nrtodification  would  provide  independent  control  of  115  VAC,  28  VDC  1,  and  28  VDC  2.  The 
recommended  design  would  be  to  switch  the  AC  and  DC  power  independently  in  a  switch  box 
located  in  the  pylon/launcher  using  discretes  from  the  station  RID  to  control  switches.  The 
relays  providing  the  power  switching  would  be  packaged  in  a  unit  which  is  physically  located 
near  the  station  RIU  in  the  pylon.  Using  the  switching  scheme  currently  employed,  the  number 
of  switching  elements  in  this  unit  would  be;  four  for  stations  3.  5,  and  7,  (two  for  28  VDC  power 
one  and  two.  one  for  1 15  VAC  power,  and  one  for  AUX  AC);  and  three  for  stations  4  and  6,  the 
air-to-air  stations  (two  for  28  VDC  power  one  and  two,  and  one  for  115  VAC  power).  Five 
discretes  from  the  station  RIU  would  be  needed  to  control  power  to  the  ECM  certified  (3,  5,  and 
7)  stations;  the  air-to-air  stations,  and  stations  4  and  6  would  need  three  each.  The  advantages 
of  this  alternative  are  as  follows:  (1)  all  changes  take  place  in  the  pylon  or  launcher,  (2)  no 
existing  equipment  is  modified,  and  (3)  an  existing  RT  on  the  W-MUX  is  utilized  and,  therefore, 
another  subscriber  to  the  W-MUX  is  not  required.  The  major  issues  are  space  in  the  pylons 
and/or  launchers,  and  availability  of  required  RIU  generated  discretes. 

6.3.1 .8  Modification  #8:  Provide  28  VDC  Auxiliary  Power  to  the  ASis  at  Stations  3,  5  and  7  - 
It  was  indicated  earlier  that  a  Class  I  interface  should  be  implemented  at  the  air-to-ground  ASis. 
It  is  further  suggested  that  Class  I A  interfaces  be  implemented  at  stations  3,  5  and  7.  This  means 
28  VDC  and  1 15  VAC  auxiliary  power  must  be  available  at  those  stations.  Three  phase  115  VAC 
is  already  planned  so  this  modification  would  implement  a  single  28  VDC.  30  amp  source  at 
stations  3.  5,  and  7.  An  additional  power  relay  off  the  DC  feed  bus  also  would  be  added.  Control 
would  be  provided  by  discretes  generated  in  the  respective  RIUs  or  by  the  RT/Logic  unit  which 
has  been  suggested  as  one  of  the  alternatives  for  controlling  the  RF  and  video  lines.  An  analysis  of 
the  power  system  needs  to  be  conducted  in  order  to  assess  the  ability  of  F-16  to  generate  the 
additional  power  required  to  p.ovide  auxiliary  28  VDC  interlaces  at  stations  3,  5,  and  7. 
Therefore,  recommendations  regarding  this  alternatives  are  TBD  pending  a  complete  power 
system  analyses  which  is  not  within  the  current  scope  of  this  study. 

6.3.1. 9  Modification  #9;  Provide  1760  Compatible  Signals  Currently  Routed  to  the  Existing 
ASis  to  each  1 760  interface  as  required  -  A  number  of  electrical  signals  currently  being  used  to 
control  stores  through  the  existing  conventional  interface  are  applicable  to  the  1760  interface 
as  well.  This  modification  would  provide  the  necessary  splices  to  make  these  signals  available  to 
the  1760  ASI.  Table  6.2  lists  the  signals  currently  available  at  or  near  the  existing  connector  at 
the  wing  air-to-ground  stations  which  are  1760  compatible.  Presented  along  with  the 
currently  assigned  name  of  each  signal  is  its  use  in  the  1760  signal  set.  Also  shown  are  the 
origins  artd  destinations  of  the  signal  in  the  pylon,  the  means  by  which  this  signal  could  be 
provided  to  the  1760  ASI,  and  the  stations  at  which  the  description  applies.  Tables  6.3  and  6.4 
present  the  same  information  for  the  air-to-air  and  centerline  air-to-ground  stations. 
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TABLE  6.2  F-16  Compatible  Signal  at  Wing  A/G  Stations  (Stations  3,  4.  6  &  7) 


F-16  SIGNAL 

1760  SIGNAL 

ORIGM 

DESTINATION 

STATIONS 

JUNCTION  PROCEDURE 

Video  A 

High 

Bandwidth  3 

Wing  Disc 
J812 

Store  Disc 
J907 

3/4/6/7 

Replace  wire  with  Y 
junction.  Connect 
single-sided  end  in  the 
Wing  Disc  (J812)  and 
conventional  connector 
(J907)  and  1760  ASI. 

Video  B 

High 

Bandwidth  4 

Wing  Disc 
J812 

Store  Disc 
J907 

3/7 

Same  as  High  Bandwidth 

O 

w 

Option  7 

Release 

Consent 

RIU  Disc 
P902 

Store  Disc 
J907 

3/4/6/7 

Replace  wire  with  Y 
junction.  Connect 
single-sided  end  in  the 
RIU  Disc  (P902)  and 
the  two  sides  of  the  Y  in 
the  conventional 
connector  (J907)  and 
1760  ASI. 

Qxi 

Interlock 

Return 

Wing  Disc 
J812 

J813 

Store  Disc 
J907 

3/4/6/7 

Splice  o«  GND/NEUT 
wire  in  the  pylon. 
Status  2  Excitation 
voltage  is  referenced  to 
the  Ground. 

Status  2 

Interlock 

Store 

Oise 

J907 

RIU  Disc 
P902 

3/4/6/7 

Replace  wire  with  Y 
junction.  Connect 
single-sided  end  in  the 
conventional  stroe  disc 
(J907)  and  two  sides  o 
the  Y  in  the  RIU 
connector  (P902)  and 
1760  ASI. 

Gtl 

Structure 

CW 

Wing  Disc 
J812 

J813 

Store  Disc 
J907 

3/4/6/7 

Splice  off  Structure 
Ground  in  the  pylon. 

Gnd/Neutral 

Power  1 
Return 

Wing  Disc 
J812 

J813 

Store  Disc 
J907 

3/4/6/7 

Splice  off 

Ground/Neutral  in  the 
pylon.  Ground  and 
Neutral  are  tied 
together  in  the  pyton. 

Gnd/Neutral 

Power  2 
Return 

Wing  Disc 
J812 

J813 

Store  Disc 
J907 

3/4/6/7 

Same  as  Power  1 

Return 

Gnd/Neutral 

115V  AC 
Neutral 

Wing  Disc 
J612 

J813 

Store  Disc 
J907 

3/4/6/7 

Same  as  Power  1 

Return 

I 
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TABLE  6.2  F-16  Compatible  Signal  at  Wing  A/G  Stations  (Stations  3,  4,  6  &  7)  continued 


F-16  SIGNAL 

1760  SIGNAL 

ORIGIN 

DESTINATION 

STATIONS 

.lUNCTTON  PROCEDURE 

Status  3 

Aux  Interlock 

RIU  Disc 
P902 

Store  Disc 
J907 

3/7 

Replace  wire  with  Y 
junction.  Connect 
single-sided  end  in  the 
mu  disc  (P902)  and 
the  two  sides  of  the  Y  in 
the  conventional 
connector  (J907)  and 
1760  ASI. 

CM 

Aux  Interlock 
Return 

Wing  Disc 
J812 

J813 

Store  Disc 
J907 

3/7 

Same  as  Interlock 
Return 

GxJ 

Aux  Interlock 
Return 

Wing  Disc 
J812 

J813 

Store  Disc 
J907 

3/7 

Same  as  Structure 
Ground 

Audo 

Low 

Bandwidth 

Wing  Disc 

Store  Disc 

3/4/6/7 

Replace  wire  with  Y 
junction.  Connect 
single-sided  end  in  the 
wing  disc.  The  two 
sides  of  the  Y  go  to  the 
conventional  connector 
and  to  the  1760  aSI. 

A-Bus 

Mux  A 

J812 

3/4/6/7 

Run  twisted  shielded 
wire  pair  from  A  Bus  in 
wring  disconnect  to 

1760  ASI 
(J81  2/J813) 

B-BUS 

MUXB 

J813 

3/4/6/7 

1 

Run  twisted  shielded 
wire  pair  from  B  Bus 
in  wing  disconnect  to 
1760  ASI 
(J81  2/.I813) 

TABLE  6.3  F-16  Compatible  Signal  at  Wing  A/A  Stations  (Stations  1 ,  2.  3A.  7A.  8,  &  9) 


F-IS  SIGNAL 

tTSO  SIGNAL 

ORIGIN 

DESTINATION 

STATIONS 

JUNCTION  PROCEDURE 

3t  VDC  AS 

RELEASE 

CONSENT 

URIU  DISC 
(P801B) 

(SPARE) 

1.  a,  JA.  7A, 

S.  B 

Run  dadlcAltd  wiru  Irom  MRIU  Olue  lo 
1TS0  ASI- 

OND 

STRUCTURE 

GNO 

WING  DISC 
(JtIO) 

PWR  SUPPLY 
OISC  (PI) 

1.  a,  JA.  TA. 

s.  • 

Spile*  eH  Stnictur*  Ground  In  llv* 

Pylon. 

WSL  PRESCNT 

INTERLOCK 

MRIU  DISC 
(PB01B) 

MISSILE  OISC 
(JSIS) 

1.  2,  JA,  TA, 
B.  S 

R*p)*c«  wiru  «Mi  V.(unc«loiL  Torminal* 
•lnol*-*ld*d  ond  In  lti«  NRiU  Oloc 
(PB01B)  ond  Uw  tao  aldo*  ol  Ut*  Y  In 

Ur*  LaunciMr  /  MluU*  discoiuwct  (JBIS) 
•nd  1T60  ASI. 

ON  /  KfUT 

POWER  1  RTF 

WING  OISC 
(JSIO) 

PWR  SUPPLY 
OISC  (PI) 

1.  a.  JA.  TA. 

s.  B 

SpBc*  oH  GM)  /  WUT  In  tiM  pylon. 

QND  /  NEUT 

WING  DISC 
(JSIO) 

PWR  SUPPLY 
DISC  (Pi) 

1.  a,  JA,  TA, 

B.  B 

Sam*  a*  peumr  1  RTN. 

GNO  /  NEUT 

IIS  VAC 

NEUT 

WING  DISC 
(JSIO) 

PWR  SUPPLY 
DISC  (PI) 

1.  X  JA,  TA, 

S.  B 

Sam*  a*  poa*r  1  RTN. 
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TABLE  6.4  F-16  Compatible  Signal  at  Centerline  Station  (Station  5) 


F-16  SIGNAL 

1760  SIGNAL 

ORON 

DESTlNATtON 

JUNCTION  PROCEDURE 

A-Bus 

Mux  A 

Fuselage  Disc 
J237 

Run  twisted  shielded  wire 
pair  from  Mux  A  Bus  Stub  to 
the  fuselage  disc  (J237)  to 
the  1760  ASI 

B-Bus 

Mux  B 

Fuselage  Disc 
J236 

Run  twisted  shielded  wire 
pair  from  Mux  B  Bus  Stub 
to  the  fuselage  disc  (J236) 
to  the  1 760  ASI 

Option  7 

Release  Consent 

RIU  Disc  P902 

Run  wire  from  RIU 
connector  {P902)  to  1760 
ASI 

Audk) 

Low  Bandwidth 

Fuselage  Disc 

.... 

Run  line  from  Audio  line  in 
Fuselaae  Disc  to  1760  ASI 

Status  2 

Interlock 

RIU  Disc  P902 

.... 

om 

Interlock 

Return 

Fuselage  Disc 
J237 

Store  Disc  J907 

Splice  off  GND  wire  in  the 
pylon.  Status  2  excitation 
voltage  is  referenced  to 
ground. 

Qra 

Structure  Grxl 

Fuselage  Disc 
J237 

Store  Disc  J907 

Splice  off  Structure  Ground 
in  the  DVion 

Gnd/Neutral 

Power  1  Return 

Fuselage  Disc 
J236 

Store  Disc  J907 

Splice  off  from  GN/NEUT 
wire  in  the  pylon 

OtJ 

Power  2  Return 

Fuselage  Disc 
J237 

Store  Disc  J907 

Sarrre  as  Power  1  Return 

Neutral 

115V  AC 

Neutral 

Fuselage  Disc 
j235 

Store  Disc  J907 

Splice  off  neutral  line  in  the 
pylon 

Status  3 

Aux  Interlock 

RIU  Disc  P902 

Store  Disc  J907 

Run  wire  from  RIU  disc 
(P902)  to  1760  ASI 

QxJ 

1 

Aux  Interlock 
Return 

Fuselage  Disc 
J237 

Same  as  Interlock  Return 

GW 

Aux  Structure 
Qtj 

Store  Disc  J907 

Same  as  structure  gnd 

6.3.1.10  Modification  #10:  Physically  locate  the  MIL-STD-1760  Primary  and  Auxiliary 
Connectors  at  Stations  3.  5  and  7  ASIs  and  the  Primary  Connector  at  All  Other  ASIs  -  This 
modification  requires  supplementing  or  replacing  the  existing  ASI  conneciors  at  each  effected 
station.  For  simple  stores,  no  modifications  or  supplemental  umbilicals  are  necessary. 
Provisioning  for  implementation  of  1760  must  accommodate  the  additional  signal  and  power 
requirements  outlined  in  the  previous  modification  descriptions,  as  well  as  several  discretes 
from  the  RIUs  serving  each  type  of  station.  Also,  the  F-I6's  existing  store  control  ability  must 
not  be  degraded.  The  1760  ASI  connectors  can  use  existing  space  if  the  present  ASI  umbilical  is 
removed  or  rerouted.  Since  some  of  the  RIU  discretes  must  be  available  through  the  1760  ASI, 
the  existing  interface  must  be  used  in  any  case.  However,  it  would  not  terminate  in  its  present 
location  at  the  rear  of  the  MAU-12  parent  rack  for  stations  3,  4,  5,  6  and  7.  Instead,  it  would 
terminate  at  or  adjacent  to  the  power  control  relay  module  added  under  other  modifications  The 
required  space  can  be  found  in  the  pin  lanyard  storage  compartment  of  the  wing  station  pylons, 
between  the  parent  ro^k  and  the  RIU  in  station  5,  and  next  to  the  missile  launcher  power  supply 
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for  stations  1,2,8,  and  9.  The  1 760  signal  set  would  be  available  at  this  location  as  provided 
from  the  power  control  module,  added  analog  lines,  and  the  RIU's  normal  ASI.  From  here,  a  new 
umbilical  would  be  routed  down  to  the  existing  ASl's  normal  location  for  mating  to  1 760  stores. 

If  no  1760  stores  are  to  be  carried,  the  new  umbilicai  would  be  removed  and  the  existing  PIU 
interface  used  as  it  is  presently.  Figure  6.23  illustrates  the  reconfiguration  described  above  for 
the  wing  pylons.  A  similar  layout  and  cable  routing  scheme  is  envisioned  for  the  centerline 
pylon,  but  the  auxiliary  power  conuol  relays  would  be  separately  located  from  the  primary 
power  relays.  The  auxiliary  power  relay  can  be  placed  in  the  forward  portion  of  the  gear  well  or 
the  pin  lanyard  compartment.  The  primary  power  control  relay  module  can  be  placed  between 
the  RIU  and  parent  rack. 


FIGURE  6.23  Proposed  Routing  and  interface  Locations,  Wing  Pylon 

The  present  missile  launcher  is  not  considered  a  canddate  for  this  mcdifioation.  Rather,  the 
Modular  Rail  Launcher  (MRL)  is  used  as  a  baseline  item.  Since  this  rail  clready  has  a  1700- 
style  ASI  for  the  AMRAAM,  the  only  'equiremeni  is  to  locate  the  power  control  module  and 
connect  the  1553  lines,  analog  lines,  and  RIU  discretes  to  a  new  1760  standard  umbilical  in  lieu 
of  the  AMRAAM  connector.  There  is  space  for  the  power  ccntrol  relays  and  necessary  terminal 
strips  next  to  the  MRL  power  supply  or  in  place  of  the  nitrogen  receiver  assembly  (USAF 
versions  of  the  AIM-9L  do  not  require  this  assembly).  The  latter  is  preferred,  since  it  offers 
nwre  space.  The  advantage  of  this  design  is  that  is  uses  existing  space  without  impacting  the 
structural  integrity  of  the  pylons  and  launchers.  The  pin  lanyard  compartment  is  adjacent  to  the 
wing/pylon  interface  and  existing  cables,  providing  easy  access  to  the  existing  umbilicals, 
additional  power,  and  analog  networx.  Another  advantage  is  that  it  is  the  least  costly  of  the 
alternatives  considered.  The  disadvantage  of  this  design  is  that  it  requires  rerouting  the  existing 
ASI  umbilical  and  removing  or  adding  the  1 760  umbilical  when  store  carriage  changes  from  an 
existing  store  to  a  1 760  store.  Of  course,  the  original  use  of  the  pin  lanyard  compartment  is 
lost,  and  new  procedures  must  be  adopted  when  weapon  safety  pins  are  rerTK>ved  before  flight. 
Finally,  although  space  for  the  new  power  control  relays  in  the  storage  compartment  is  adequate, 
the  space  for  rerouting  umbilicais  is  marginal.  In  fact,  the  centerline  pylon  will  require 
additional  wiring  for  connectivity  with  the  auxiliary  power  control  relays  to  their  location. 
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6.3.1.11  Modification  #11:  Provide  the  Additional  ACIU  Hardware  and  Software  to  Co.ntrol 
MIL-STD-1760  Stores  and  to  Implement  the  Changes  in  the  Operational  Flight  Program 
Required  by  the  Suggested  Modifications  -  Paragraph  6.2.4  defines  the  requirements  for 
modification  of  the  SMS  in  order  to  implement  MIL-S'i  D-1760.  The  system  design  previously 
indicated  affects  the  ACIU  in  a  number  of  ways.  Firstly,  the  new  units  and  the  MIL-STD-1760 
discretes  that  the  remote  units  now  control,  place  an  additional  processing  load  on  the  ACIU. 
Secondly,  the  new  MIL-STD-1760  stores  place  an  additional  software  requirement  on  the  ACIU 
Thirdly,  the  requirements  for  interoperability  implicit  in  MIL-STD-1760A  and  draft  notice  1 
LDD  place  an  additional  processing  and  software  requirement  on  the  ACIU.  Lastly,  the 
requirements  of  the  LDD  force  changes  to  be  made  to  the  MIL-STD-1553  bus  controlltr  in  the 
ACIU.  This  is  because  to  produce  an  ACIU  that  is  capable  of  handling  1760  stores  in  generic 
manner  it  must  be  capable  of  generating  and  checking  the  LDD  sumcheck.  The  timing  constraints, 
in  relation  to  the  gerieration  of  LDD  sumchecks  and  system  time  are  such  that  these  functions 
must  be  performed  in  hardware.  The  only  place  for  incorporation  of  this  hardware  is  the  ACIU 
bus  controller.  If  only  restricted  sub  sets  of  stores  are  used,  i.e.  *hose  stores  that  do  not  use  the 
features  above,  then  the  ACIU  BCU  may  not  require  modification. 


6.3.1.11.1  Scope  of  Modifications  -  The  modifications  considered  are  only  those  required  to 
meet  the  system  design  (see  paragraph  6.3).  MIL-STD-1760A  and  LDD  Notice  1.  The 
modifications  made  to  the  ACIU  assume  that  system  interoperability  for  future  MIL-STD-1760 
stores  is  of  prime  impKinance.  To  this  end  the  software  modifications  are  extended  to  provide  for 
system  reconfiguration  as  dictated  by  the  store  description  message. 


6.3.1.11.1.1  Limitations  -  The  design  modifications  consider  the  ACIU  as  it  was  specified  in 
August  1985,  any  changes  made  after  this  date  have  not  been  considered.  The  recommended 
changes  are  the  minimum  that  are  required,  consistent  wiih  the  correct  operation. 

6.3.1.11.2  Requirements  Summary  -  The  previous  paragraph  6.3.1  defines  the  system  changes 
that  are  required  of  the  complete  SMS.  Figure  6.24  shows  the  current  ACIU  hardware  design  and 
figure  6.8  shows  the  current  software  design.  The  requirement  is  to  modify  the  ACIU  in  as  few 
ways  as  possible,  whilst  allowing  it  to  control  the  new  hardware  and  to  enable  the  stores 
management  system  to  manage  the  new  MIL-STO-1760  stores  in  their  defined  loadout 
TOnfigurations.  The  following  issues  relate  directly  to  the  required  modifications  of  the  ACIU 
"^‘^^ssitated  changes  to  the  ACIU  to  ensure  that  the  SMS  fully  implements 
MIL-STD-1760  and  hence  increases  the  level  of  interoperability  of  the  system.  The  issues  are- 


a.  The  control  and  timing  of  Release  Consent  when  controlled  over  a  dual  standard  serial 
data  bus  -  The  specification  requires  that  Release  Consent  is  present  at  the  ASI  for  20  msec 
prior  to  safety-critical  data  transfer.  The  use  of  remote  switching  units  means  that  the  total 
data  transfer  and  signal  activation  time  must  be  taken  into  account.  Release  Consent  must  be 
enabl^  as  late  as  is  possible  in  the  release  cycle  tc  ensure  safety.  This  is  especially  important 
when  dual  standards  are  used  on  the  ASI  digital  data  bus.  However,  to  ensure  that  the  stoVe  is 
reeased  suwessfully.  the  signal  must  be  present  at  the  ASI  20  msec  prior  to  the  transmission  of 
safety-cntic^  commands.  To  ensure  that  the  above  requirement  is  satisfied  the  command  settino 
Consent  must  be  initiateo  by  the  ACIU  at  least  100  msec  prior  to  the  transmission  of 
the  Fire/l^unch  safety-critical  message.  This  is  because,  the  remote  units  are  still  to  be 
TOntrolled  over  th^e  existing  dual-simplex  bus.  Thu  100msec  period  is  required  to  allow  the 
ACIU  to  command  Release  Consent  on.  wail  for  the  signal  to  be  activated  by  the  remote  unit,  and  to 
monitor  correct  operation,  prior  to  a  safety  critical  command. 
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FIGURE  6-24  Current  ACIU  Hardware  Design 
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b.  Control  of  Safety-Critical  functions  -  Two  methods  are  provided  within 
MIL-STO-1 760A  for  the  aircraft  to  provide  a  safety  interlock.  They  are  Release  Consent  and  28 
volts  DC  power  2.  To  allow  any  Stores  Management  System  to  function  in  a  fully  interoperable 
manner  the  store  functions  must  be  described  (in  some  manner)  to  the  SMS  by  the  store.  The 
preferred  method  of  interlock  for  stores  is  via  the  use  of  Release  Consent.  However,  to  satisfy 
the  requirerrents  of  MIL-STD-1760A  it  is  necessary  that  the  ACIU  provide  both  release  consent 
and  28  volts  2. 

c.  1553  Redundancy  us  appropriate  to  the  1760  LDD  -  In  the  current  ACIU  design, 
MIL-STO-1 553  redundancy  is  achieved  by  providing  a  completely  ‘shared  and  split' 
architecture  with  ACIU,  ie.  Bi.s  A  (BC)  and  Bus  B  BC  are  separate  and  redundant.  Bus  controller 
A  can  control  both  buses,  but  BC  B  only  controls  bus  B.  What  action  does  BC  A  take  upon  finding 
that  it  cannot  communicate  or>  bus  B?  The  fault  could  be  itself,  in  which  case  changing  the  BCs 
will  return  Bus  B  (but  there  will  be  no  Bus  A  communication).  Alternatively,  the  fault  could  be 
the  bus  itself  -  in  which  case  changing  BCs  will  result  in  no  communication  at  all.  The  prevision 
of  partial  redundancy  is  not  in  keeping  with  LDD  or  MIL-STD-1553.  A  fault  which  causes  ACIU 
half  switching  means  utilizing  BC  B,  which  is  only  capable  of  communicating  on  Bus  B  even 
though  there  is  no  fault  with  Bus  A.  This  situation  will  require  modification  to  ensure  that  full 
future  interoperability  is  provided. 

d  Store  description  messages  -  The  notice  1  LDD  provides  a  requirement  that  stores 
contain  a  number  of  description  pages  that  define  the  stores  operational  and  control 
requirements.  This  information  allows  the  SMS  to  function  in  a  completely  interoperable 
manner;  that  is,  the  SMS  requires  no  inventory  configuration  prior  to  the  upload  of  store 
description  messages.  The  ACIU  software  will  require  modification  to  take  account  of  this. 

e.  ACIU  Bus  Controller  is  required  to  support  a  750-microsecond  intermessage  gap  • 
The  ACIU  BC  will  require  modification  to  ensure  that  this  requirement  can  be  met. 

f.  LDD  message  checksum  •  The  ACIU  W-bus  does  not  currently  support  the  generation 
of  LDD  checksum.  No  software  solution  exists,  therefore,  the  hardware  will  require 
modification. 

g.  Aircraft  system  time  usage  •  Stores  that  require  system  time  will  need  to  be  well 
synchronized  (less  than  2  msec  error)  with  aircraft  time.  To  ensure  that  this  is  possible 
hardware  mechanisms  should  be  used  for  time  synchronization.  The  AEIS  bus  controller  n;ust 
maintain  a  synchronized  version  of  system  time  so  that  the  system  time  entity  can  be  loaded  into 
the  appropriate  messages  at  the  point  of  transmission.  To  ensure  this  is  possible,  hardware 
mechanisms  must  be  used  for  the  LDD  sumcheck  word.  This  will  allow  messages  containing 
system  time  to  be  transmitted  with  the  minimum  of  time  error.  Synchronization  at  these  levels 
of  accuracy  is  generally  not  possible  vith  software.  System  time  is  required  to  be  transmitted  to 
those  stores  that  require  it.  It  must  be  accurate  to  better  than  2msec.  To  achieve  this  level  of 
accuracy  the  BCU  will  have  to  place  the  current  system  time  in  the  message  at  the  point  of 
transmission  and  (for  those  stores  that  require  it)  include  the  LDD  sumcheck.  It  is  not  possible 
to  perform  this  mechanism  in  software  alone. 

6.3.1.11.2.1  Processor 

a  Current  Performance  The  current  fit  of  main  processor  in  each  redundant  portion  of 
the  ACIU  is  compatible  with  the  MIL-STD-1750  Instruction  Set  Architecture.  It  executes 
instructions  at  120K  instructions  per  second  (ips),  when  measured  using  the  Discrete  Avionics 
Instruction  Set  (DAIS)  benchmark. 
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b.  MIL-STD-176Q  Required  Performance  Conventional  SMS  processing  environments 
do  not  require  very  large  processing  power  capabilities.  This  is  because  only  a  relatively  small 
part  of  the  large  SMS  software  set  is  running  at  any  time,  due  to  the  event  driven  nature  of  SMSs. 
This  is  combined  with  the  fact  only  on'>  store  type  is  normally  controlled  at  any  one  time, 
although  systems  managing  multiple  types  of  MIL  STO-1760  stores  may  be  required  to  control 
two  types  simultaneously.  Close  study  shows  the  worst  case  situation  is  during  the  prerelease 
phase  of  missile  control,  when  targeting  of  the  missile  is  required  using  digital  serial  links 
between  the  controlling  system  and  the  missile.  Each  missile  to  be  simultaneously  targeted  by 
the  ACIU  increases  the  processing  load  by  an  amount  approximately  in  proportion  to  the  data 
unique  to  each  additional  store  (This  is  because  certain  data  will  be  common  to  all  stores  and  will 
not  require  individual  processing  on  a  per-store  basis).  An  influential  factor  in  the  estimate  of 
required  processing  power  is  the  format  of  data  received  from  the  Avionics  Bus.  This  factor 
results  from  the  fact  that  data  gathering  and  reformatting  of  the  required  data  is  a  major 
component  of  processor  load.  As  an  example  of  the  likely  requirements  of  the  ACIU  performance 
when  controlling  MIL-STD-1760  stores,  it  is  representative  to  take  the  case  of  AIM-t20 
(AMRAAM).  This  store  significantly  loads  the  processor  during  the  pre-launch  phase,  and 
involves  data  transfer  to  the  store  using  MIL-STD-1553  serial  links.  While  this  store  does  not 
strictly  operate  to  the  MIL-STD-1760  LOD,  the  number  and  frequency  of  data  transfers  will  be 
of  the  same  order  as  LDO  compatible  stores.  Experience  shows  that  the  AIM-120  processing 
loads  are  0.25  MIPS  for  one  AIM-120  during  targeting  and  0.38  MIPS  for  two  AIM-1 20s  during 
targeting.  These  numbers  assume  a  50  KHz  update  rate,  target  code  produced  from  a  non 
optimizing  Ada  compiler,  and  significant  data  derivation  and  conversion.  These  figures  make  no 
allowance  for  any  other  processing  activity  during  targeting.  It  would  be  prudent  to  allow  0.05 
Mips  for  other  data  gathering  and  conversion,  and  a  further  0.05  Mips  for  support  and 
housekeeping  activities.  It  is  important  to  note  that  the  single  AIM-120  figure  of  0.25  Mips  is 
beyond  the  capability  of  the  current  processor  according  to  received  data.  This  implies  that 
either  the  data  is  erroneous  or  that  a  lower  update  rate  is  being  used  or  that  highly  optimized 
assembler  code  is  being  used  with  little  data  conversion.  It  should  also  be  noted  that  if  Ada  were 
to  be  chosen  as  the  HOL,  the  processing  power  requirement  is  higher  in  development 
environment  than  the  delivered  one.  This  is  due  to  the  use  in  development  of  run  time  featuies; 
(for  example,  constraint  checking)  which  may  be  omitted  in  the  final  version  of  the  ope'^ationa! 
flight  program.  These  figures  suggest  a  requirement  exceeding  0.35  Mips  (single  targeting)  or 
0.48  Mips  (twin  targeting).  Anticipating  a  future  expansion  requirement  of  50%,  a  processor 
capable  of  around  0.75  Mips  is  desirable. 

c.  Possible  Implementations  -  The  standard  options  towards  increasing  the  processor 
power  of  an  existing  unit  are; 

( 1  )  Add  extra  processors  of  identical  design  to  the  existing  processor  (Five 
additional  ones  are  required  in  the  case  of  the  ACIU) 

( 2  )  Add  an  extra  processor  of  different  design  to  make-up  the  processing 

shortfall 

( 3  )  Completely  replace  the  existing  processor  by  a  new  design 

Options  a)  and  b)  comprise  multi-processor  solutions,  aiid  knowledge  of  the  motherboard  design 
may  prohibit  these  solutions.  This  is  because  there  may  not  exist  either  the  physical  locations 
for  extra  modules,  or  the  necessary  motherboard  control  signals  for  multi-processor 
applications.  The  most  viable  option  is  that  of  redesigning  the  processor  module  to  provide  the 
required  processing  power.  Ideally,  this  would  retain  MIL- STD- 1750  compatibility  in  order  to 
preserve  the  existing  software  suite. 
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6.3.1.11.2.2  Memory 

a  Current  Capacity  -  The  ACIU  is  currently  comprised  of  16K  RAM  and  48K  PROM  per 
redundant  portion  of  the  LRU  (with  some  overlap  between  halves  in  the  RAM  area). 

b.  MIL-STD-176Q  Required  Performance  -  Assuming  that  the  conventional  stores 
continue  to  be  controlled  by  the  existing  software  suite,  and  that  MIL-STD-1760  stores  will  be 
controlled  by  Ada  packages,  experience  from  the  AVS  demonstration  rig  would  indicate  a 
requirement  breakdown  as  follows: 

( 1  )  Application  Packages  - 


Initialization 

1500 

lines 

of 

Ada 

Event  Processing 

1300 

lines 

of 

Ada 

Cold/Warm  Restart 

1000 

lines 

of 

Ada 

Store  State  Management 

7000 

lines 

of 

Ada 

Jettison  Management 

1000 

lines 

of 

Ada 

Test/Reversion  modes 

800 

lines 

of 

Ada 

12600 

Total 

(  2 )  SMS  Services  - 


Event  Identification 

300 

lines 

of 

Ada 

Safety-Critical  Monitor 

1000 

lines 

of 

Ada 

Power  Control/Monitor 

500 

lines 

of 

Ada 

W-MUX  Interfacing/Monitor 

2000 

lines 

of 

Ada 

RIU  Control/Monitor 

800 

lines 

of 

Ada 

Error  Retry/Identification 

500 

lines 

of 

Ada 

IBIT  Control/CBIT 

1000 

lines 

of 

Ada 

Network  Setup/Monilor 

800 

lines 

of 

Ada 

6900 

Total 

This  gives  a  total  of  19,500  lines  of  Ada  code.  Converting  to  bytes,  at  10  bytes  per  line,  a 
figure  of  195  K  bytes  of  storage  is  required  for  code  (that  is  195K  by1es  PROM).  Data  storage 
requirements  are  estimated  at  20K  bytes  for  LDD  data  entities,  and  a  further  40  K  bytes  each 
for  the  Ada  ’stack"  and  "heap,"  resulting  in  1 00  K  bytes  of  RAM.  Applying  50%  future 
expansion  capacity,  memory  requirements  are  PROM  -  300  K  bytes  and  RAM  -  150  K  bytes. 
The  ACIU  clearly  requires  a  memory  expansion. 

c.  Possible  Implementations  -  Memory  technology  has  progressed  significantly  in 
recent  years.  Unless  the  ACIU  has  sufficient  spare  physical  capacity  to  accommodate  repeat 
memory  modules  (unknown,  but  unlikely),  a  redesign  would  be  indicated.  The  required  memory 
densities  are  now  available  on  a  single  module  when  utilizing  hybrid  memory  components  and 
surface  mounting  techniques.  At  this  time,  the  entire  PROM  requirement  may  be  exceeded  by 
utilizing  three  (3)  1  M  bit  EPROM  devices.  Alternatively,  EEPROM  devices  should  be 
considered  for  their  on-board  reprogramming  capability.  It  is  also  likely  that  the  processor  and 
memory  redesigns  should  be  considered  jointly,  since  memory  "paging*  techniques  may  then  be 
avoided. 

6.3.1.11.2.3  W-MUX  -  Modifications  to  the  W-MUX  Bus  Controi  module  may  be  unnecessary. 
The  key  points  which  will  resolve  this  issue  are  driven  by  the  LOD  and  are  given  below: 
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a*  Intef-messaoe  gap  perfomrirnce  -  The  LDD  requires  that  the  bus  controller  to  the 
1760  stores  (in  this  implementation,  the  ACIU)  ‘s  able  to  support  a  750  micro  secorxl  inter¬ 
message  gap  time.  ACIU  performance  in  this  area  is  unknown,  and  indeed  may  change  from  its 
current  value  when  a  higher  performance  central  processor  unit  is  insialleJ  (depending  on 
actual  ACIU  bus  controller  design). 

b.  Mode  Codes  ■  The  LOD  mandates  certain  mode  codes  to  be  supported  by  the  W-MUX  bus 
controller.  It  is  unlikely  that  the  ACIU  will  be  unable  to  support  these,  but  neither  is  it  possible 
to  state  that  it  does  possess  the  required  capability. 

c.  Checksums  -  The  LOT  requires  that  the  final  word  of  any  message  is  a  checksum  word 
relating  to  that  message.  This  requires  that  the  ACIU  W-MUX  bus  controller  either  evaluate  the 
checksum  in  software  prior  to  message  transmission  (adding  to  the  processing  load  and 
potentially  the  inter-messag*-  gap),  or  add  a  hardware  checksum  generating/receiving 
mechanism  to  the  bus  controller.  The  second  option  may  be  prohibited  by  space/layout 
considerations,  but  would  represent  the  preferred  solution  from  a  performance  viewpoint. 

6.3.1  tt. 2.4  Discretes  -  The  ACIU  in  the  proposed  recommended  implementation  is  required  to 
control  the  auxiliary  28V  DC  supplies  via  discrete  control  of  power  relays.  Details  available  to 
the  case  study  design  team  relating  to  the  input/output  modules  within  the  ACIU  are  insufficient 
to  determine  if  sufficient  spare  capacity  exists,  and  thus  avoiding  ACIU  modification. 

6.4  IMPLEMENTATION  SUMMARY  Implementation  of  the  suggested  ntodifications  requires  the 
efforts  summarized  below.  These  implement  the  requirements  defined  in  paragraph  6.3. 

a  Implementing  a  new  HBW  50  ohm  (RF)  switching  network. 

b.  Adding  an  additional  remote  terminal  to  the  W-MUX  Bus  and  connecting  it  to  the  RF 
switching  network  with  43  discrete  lines  and  to  the  Video  Switching  Network  with  28  discrete 
lines. 

c.  Adding  a  40  cubic  inch  switching  unit  in  all  the  pylons  and  launchers  to  control  the 
switching  of  the  primary  power. 

d.  Adding  a  44.3  cubic  inch  switching  unit  in  the  pylons  at  stations  3  and  7  and  in  the 
aircraft  near  station  5  to  control  auxiliary  AC  power.  Three  additional  wires  for  power  and  one 
additional  discrete  line  will  also  have  to  be  installed  between  the  aircraft  and  the  pylon. 

e.  Implementing  auxiliary  28  VDC.  Current  indications  are  that  both  the  required 
relays  and  wiring  changes  should  be  located  in  the  equipment  bays  aft  of  the  cockpit. 

f.  Running  eight  additional  RF  lines  from  the  RF  Switching  Matrix  to  the  station 
disconnects. 

g.  Running  three  video  lines  from  the  Video  Switch  to  the  three  interior  air-to-ground 
stations  (one  video  line  per  station)  and  extending  the  video  lines  from  the  provisionary 
connectors  to  a  1760  ASI  at  the  air-to-air  stations. 

h.  Adding  three  additional  relays  to  the  Video  Switch  lo  accomi'todate  the  three  new  video 
lines  mentioned  above. 

i .  Performing  a  number  of  wiring  changes  in  the  pylons  and  launchers  in  order  to 
provide  currently  available  signals  to  the  1760  ASI. 
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j .  Extending  the  W-MUX  Bus  out  of  the  W-MUX  station  matrices  to  the  1760  ASI  at  the 
air-to-air  stations. 


k.  Placing  higher  rated  circuit  breakers  in  the  DC  power  feed  lines  to  the  Stores  Standby 
Power  System. 

l .  Implementing  logical  changes  to  accommodate  all  modifications. 

m.  Increasing  the  ACID  processor  power  and  memory  capacity. 

6-4.1  Implementation  of  Specific  1760  Functions  Overall  implementation  of  a  desired 
MIL-STD-1760  capability  in  the  F-16  C/D  impacts  the  following  general  areas:  HBW  signals, 
power,  discrete  signals,  and  the  SMS  logic.  The  following  paragraphs  summarize  how  the 
implementation  baseline  would  address  the  impact  in  each  area. 

a  HB\Y  Signals  -  A  separate  50-ohm  HBW  network  coukJ  be  implemented  in  the  aft 
equipment  bay.  It  would  control  the  switching  of  all  HB1  and  HB2  signals.  HB3  and  HB4  would 
be  switched  by  the  existing  video  network.  Three  additional  switching  elements  could  be  added  to 
the  video  switches  to  accommodate  the  three  new  video  lines.  Switching  in  both  HBW  switching 
networks  (50  ohm  -  RF,  75  ohm  -  Video)  would  be  in  response  to  discretes  generated  by  a 
remote  terminal  on  the  W-MUX  Bus.  This  remote  terminal  could  be  located  in  the  aft  equipment 
bay.  Control  words  would  be  communicated  from  the  ACIU  to  the  tiew  remote  terminal  over  the 
W-MUX  Bus  in  dual-simplex  protocol.  An  address  of  11100  would  be  assigned  to  this  terminal. 
This  address  is  currently  reserved  as  a  spare  in  the  W-MUX  dual-simplex  address  field. 

b.  Eflwec  -  Switching  units  distributed  in  the  pylons  and  in  the  launchers  could  control 
primary  AC  and  DC  power  at  each  station.  One  implementation  of  such  a  switching  unit  consists 
of  five  electromechanical  relays  of  the  same  type.  Relays  are  currently  available  in  industry 
which  provide  the  required  switching  capacity  at  the  parameters  specified  by  MIL-STD-1760. 
The  typical  size  for  such  a  relay  is  1.718  inches  (length)  x  0.525  inches  (width)  x  1.125 
inches  (height).  Taking  into  consideration  proper  thermal  drain  constraints,  a  box  of  size  5.3 
inches  (length)  x  3  inches  (width)  x  2.5  inches  (height)  should  accommodate  these  relays  along 
with  accompanying  wiring.  A  20-pin  connector  (16  for  power  and  control  grounds,  4  spares) 
k^ted  on  top  of  the  box  would  provide  connectivity  to  the  other  elements  of  the  stores  power 
distribution  network.  Auxiliary  AC  power  could  be  controlled  at  the  store  stations  using  a  single 
switching  unit  located  at  each  of  the  three  ECM  certified  stations  (3,  5,  and  7).  This  switching 
unit  could  be  implemented  using  a  single  three-pole  single-throw  (TPST)  electromechanical 
relay.  The  size  of  such  a  relay  is  approximately  3.72  inches  (length)  x  3.303  inches  (width)  x 
2.4  inches  (height).  A  box  4.5  inches  (length)  x  4.1  inches  (width)  x  3.2  inches  (height) 
designed  with  the  proper  thermal  considerations  could  house  the  relay.  A  10-pin  connector  (7 
for  power  and  oontrm  grounds.  3  spares)  would  provide  connectivity  to  the  other  elements  of  the 
store  power  distributiori  network.  The  exact  source  of  auxiliary  DC  power  was  undetermined  due 
to  the  lack  of  information  concerning  F-16  power  distribution.  However,  it  is  reasonable  to 
assume  that  the  source  would  be  located  at  the  aircraft  power  distribution  level.  Furthermore, 
it  can  be  assumed  that  to  extend  these  three  DC  sources  to  stations  3,  5,  and  7  would  require 
runnirtg  a  dedicated  wire  from  power  sources,  located  most  likely  in  equipment  bays  aft  of  the 
cockpit,  to  each  of  the  stations.  Therefore,  the  relays  controlling  the  auxiliary  28  VDC  power 
lines  could  be  implemented  ij.  the  aircraft  during  installation  of  the  wiring.  Control  of  the 
relays  would  most  likely  be  provided  via  discretes  from  the  ACIU  discrete  I/O  board. 

Space  to  accommodate  the  5.3  inches  x  3  inches  x  2.5  inches  primary  power  switching  unit  is 
available  in  both  the  winy  and  centerline  pylons,  and  the  air-to-air  missile  launchers  The  pin 
storage  compartment  of  the  wing  pylon  represents  available  space  of  the  approximate  dimensions 
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12  inches  x  5  inches  x  6  inches.  This  space  can  easily  accommodate  both  the  primary  power 
switching  unit  and  the  4.5  inches  x  4.1  inches  x  3.2  inches  auxiliary  AC  power  switching  unit.  A 
6  inches  x  5  inches  x  6  inches  space  located  between  the  RIU  and  pylon  bomb  rack  could  be  used 
to  house  the  primary  switching  unit  and  associated  wiring  in  the  centerline  pylon.  However,  the 
auxiliary  AC  switching  unit  for  the  centerline  station  will  have  to  be  located  in  the  aircraft  due 
to  a  lac*  of  available  space  in  the  pylon.  An  area  near  the  power  supply  in  the  launchers  could  be 
used  to  accomnHKiate  the  primary  power  switching  unit  at  the  air-to-air  stations. 

c.  Discretes  •  The  discretes  to  the  1760  interface  could  be  generated  by  the  station  RID 
or  provided  from  discrete  lines  currently  being  routed  to  the  conventional  connector.  A  slight 
modification  to  the  data  selection  portions  of  the  RtU  must  be  accomplished  before  STATUS  2  and 
3  could  be  used  for  Interlock  arid  Auxiliary  Interlock,  respectively.  Threshold  values  and 
excitation  current  levels  must  be  adjusted  to  1780  values  when  the  RIU  is  interfacing  to  1760 
stores.  The  1760  addresses  could  be  generated  by  mating  the  proper  address  lines  to  the  address 
return  line  at  the  1760  ASI.  This  mating  could  be  accomplished  by  running  the  wires  for  the 
address  lines  in  the  1760  ASI  to  a  tag  strip  located  in  an  LRU  in  the  pylon.  The  RIU  and  primary 
power  switching  unit  are  both  candidate  LRUs  for  this  task. 

d.  Logical  -  While  definirtg  the  changes  required  to  be  made  in  the  ACIU  to  imp>lement  the 
requirements  of  MIL-STD-1760,  it  has  become  evident  that  a  great  deal  of  data  relating  to  the 
existing  design  is  required.  The  information  must  covor  ihe  existing  system  performance 
requirements,  hardware  and  software  design  definitions.  Insufficient  data  was  available  on  the 
first  two  of  these  aspects  to  allow  a  detailed  definition  of  tfie  design  changes  to  be  made. 
Nevertheless,  a  considerable  amount  of  data  was  made  available.  The  lesson  to  be  leiirned  is  that 
very  specific  data  is  rec.uired  (all  of  which  may  not  be  published),  in  order  to  define  the  changes 
that  are  required  to  an  existing  SMS  processor  (such  as  the  ACIU)  to  enable  it  to  support  all  the 
requirements  of  MIL-STD-1760,  as  the  result  of  an  improvement  program.  However,  this 
design  activity  has  determined  those  functional  elements  of  the  ACIU  which  would  need  to  be 
upgraded,  should  a  full  implementation  of  MIL-STD  1760  be  required.  The  principal  changes 
that  need  to  be  made  are  associated  with  the  usage  of  the  MIL-STD-1553B  data  bus  for  MIL- 
STD-1 760,  the  implementation  of  the  LDD  message  sumchecks  and,  most  significantly,  the 
implementation  of  the  LDD.  These  requirements  impose  a  significant  increase  in  processing 
power  and  memory  capacity  for  the  ACIU  processors.  Increases  by  factors  of  six  (6)  and  ten 
(10),  respectively,  would  be  needed  to  comply  with  these  requirements.  A  detailed 
implementation  design  approach  is  not  pract'cable  at  this  stage  without  more  information 
relating  to  the  existing  ACIU  hardware. 

6.5  CASE  STUDY  SUMMARY  The  F-16  C/D  Case  Study  has  shown  that  for  aircraft  in  general,  the 
primary  aircraft  system  affected  by  MtL-STD-1760  is  the  Stores  Management  System.  In 
addition  to  impacting  the  interface  at  the  physical  ASI  locations,  1760  also  affects  SMS  endpoints 
within  the  aircraft  which  are  connected  to  the  ASIs.  These  endpoints  issues  include:  indirect 
requirements  due  to  concurrent  operation  of  multiple  ASIS,  message  and  protocol  requirements 
on  the  1760  data  bus  applied  to  the  SMS  bus,  and  characteristics  of  sinks  and  sources  within  the 
aircraft  which  interface  with  the  ASI. 

6.5.1  Power  System  Depending  on  the  specific  definition  of  SMS  boundaries,  1 760  could  also 
affect  the  aircraft  power  generation  and  distribution  system.  At  the  overall  aircraft  system 
level,  the  electrical  load  of  the  power  generation/conversion  system  is  impacted  by  the  total  load 
of  all  ASIs  operating  simultaneously.  To  this  extent,  1760  defines  the  maximum  load  at  each  ASI. 
MIL-STD-1760  does  not,  however,  require  that  the  aircraft  be  capable  of  simultaneously 
operating  all  ASIs  at  maximum  rating.  The  interoperability  goals  of  1760  can  be  simplistically 
defined  as  permitting  installation  of  any  store  at  any  station  on  any  airaaft.  The  ability  of  any 
store  type  to  be  operated  simultaneously  at  all  stations  of  an  aircraft  does  rK>t  necessarily  apply. 
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even  though  this  capability  could  be  desirable.  A  second  power  system  impact  could  deal  with 
power  quality  issues.  Because  MIL-STD-704  has  D  as  the  current  issue,  any  invitation  to  bkl  oi 
request  for  proposal  against  MIL-STD-1760A  installation  may  cause  MIL-STD-1760  to  impose 
requirements  on  power  characteristics  at  the  ASI  which  are  not  d'rectly  compatible  with  present 
aircraft  power  systems.  This  does  not.  however,  mean  that  the  entire  aircraft  power  system 
must  comply  with  the  1760  power  requirements. 

6.5.2  Avionics  System  Interfaces  The  final  aircraft  system  area  details  with  'avionics*  system 
interfaces.  MIL-STD-1760  may  standardize  particular  signal  interfaces  which  are  related  to 
specific  subsystems.  This  standardization  does  not.  however,  imply  tha*  the  aircraft  must 
contain  such  subsystems.  For  example,  1 760  may  define  a  high  bandwidth  transfer  media 
compatible  with  GPS  Li  signal  bands.  This  signal  definition  does  not,  however,  mandate  that  the 
host  airaaft  contain  a  GPS  receiver.  The  host  aircraft  should,  however,  contain  the  transfer 
media  routed  to  some  ‘convenienr  point  in  the  aircraft.  Likewise,  1760  may  define  a  message 
format  for  transferring  terrain  map  data  to  a  store,  but  this  definition  does  not  imply  that  all 
aircraft  carry  or  process  digital  terrain  maps.  In  general,  it  is  not  the  intent  of  1760  to  control 
or  influence  the  basic  mission  capability;  (that  is,  role)  of  an  aircraft  weapon  system,  but  to 
standardize  those  interfaces  when  they  exist.  This  general  1 760  limitation  is  even  more  true 
for  mission  stores.  Most  of  the  standardized  interfaces  defined  for  the  MSI  in  1 760  will  not  be 
used  by  any  specific  mission  stores  (This  does  not,  however,  exclude  use  of  a  common 
connector).  Where  a  mission  store  requires  a  spedfio  interface  signal,  the  characteristics  must 
comply  with  1 760.  Since  a  carriage  store  may  be  inserted  between  interoperable  aircraft  and 
mission  stores,  and  since  the  carriage  store  may  be  produced  by  a  third  party,  tighter  controls  of 
17^C  interfaces  are  projected  for  the  carriage  stores.  MIL-STD-1760  incorporate  some 
provisions  to  allow  the  carriage  store  protocol  to  be  added  later  by  restricting  the  message  length 
for  Mission  Stores  to  30  words.  The  two  remaining  words  are  effectively  reserved  for  use 
within  the  protocol  for  the  routing  of  data  directly  through  a  carriage  store.  The  1760  interface 
on  the  aircraft  or  a  mission  store  extends  a  limited  distance  into  the  aircraft  or  mission  store. 
Beyond  this  limited  boundary,  the  interface  has  no  control.  In  contrast,  the  interface  extends 
into  a  carriage  store  from  two  directions  -  from  the  CSI  and  from  the  CSSI.  In  addition,  the 
carriage  store  should  be  functionally  transparent  to  a  mission  store:  that  is.  a  mission  store 
should  operate  the  same  whether  singly  carried  or  multiply  carried.  MIL-STD-1760  should 
define  all  commar>ds.  protocols,  topologies  arxJ  electrical  characteristics  necessary  for  achieving 
this  transparency.  MIL  STD-1760  essentially  forms  the  electrical  specification  for  the  store. 

6.5.3  Ground  Support  Equipment  The  final  area  of  1 760  impact  is  on  Ground  Support 
Equipment  (GSE).  Specific  GSE  items  will  be  necessary  for  testing  the  various  weapon  system 
segments  at  each  1760  interface.  MIL-STD-1760  will  impact  these  GSE  items  by  defining  the 
interface  between  the  GSE  and  the  applicable  1760  connection  point.  Depending  on  the  specitic 
GSE  function,  other  non-1760  interfaces  may  also  be  required  for  accomplishing  the  ground 
tests  or  maintenance  actions.  MIL-STD-1760  will  not.  however,  address  specific  GSE  to 
aircraft,  GSE  to  carriage  store,  or  GSE  to  mission  store  functional  requirements.  While  it  might 
be  desirable  to  develop  a  standard  set  of  GSE  for  use  on  all  aircraft  and  stores,  the  testirrg 
procedures  and  fault  location  algorithms  will  vary  between  different  aircraft  and  between 
airaaft  stores.  For  this  reason,  1760  does  not  address  these  GSE  requirements.  For  example,  it 
is  not  the  standard  ASI  that  is  tested  on  an  airaaft.  but  a  specific  SMS  implementation  of  1760. 

If  a  failure  is  evident  at  the  ASI,  the  GSE  must  peer  into  the  SMS  through  the  ASI,  and  probably 
through  other  airaaft  interfaces,  to  determine  the  cause  of  the  failure.  Likewise,  the  location  of 
a  failed  component  witnin  a  carriage  store  coukJ  require  different  procedures  and  algorithms  for 
different  carriage  stores. 
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6.5.4  Summary  In  summary.  1760  should  standardize  only  those  interface  issues  necessary 
for  achieving  interoperability  between  aircraft  ar>d  stores.  The  impact  of  1760  on  the  weapon 
systems  should  be,  therefore,  limited  to  those  areas  necessary  for  interoperability.  During 
dwelopment  of  new  1760  systems,  a  fine  line  will  exist  between  defining  some  1760 
requirements  (whk^  enhance  interoperability)  and  infringing  on  the  specification  domain  of 
various  subsystems.  Most  ‘requirements*  which  specify  design  implementation  details  could 
overstep  the  authority  of  1760  and.  more  importantly,  are  not  necessary  to  ensure 
interoperability.  The  biggest  problem  in  defining  the  proper  domain  or  boundaries  of  the  1760 
requirements  occurs  in  determining  how  ‘deep’  into  an  interface  segment  (that  is.  aircraft)  that 
requirements  must  be  defined.  A  good  example  of  this  borderline  area  is  the  perceived  need  for 
deadfadng  interface  circuits.  The  deadfadr^g  issue  deals  with  the  termination  of  interface 
circuits  after  release  of  a  store.  Ceadfacing.  in  this  context,  is  not  an  interoperability  issue.  It 
may  be  desirable  to  deadface  some  circuits  to  minimize  the  posstoilHy  of  damage  or  to  limit 
pick-up  of  EMI  on  the  unterminated  circuits.  These  factors  affect  performance  of  the  SMS  (for 
the  aircraft  interface  segment)  or  the  store  electronics  (for  the  store  interface  segment).  The 
SMS  arto  store  side  of  the  interfaces  should  be  designed  such  that  these  factors  do  not  impact 
operation  of  the  remaining  active  interfaces,  or  impact  the  interoperability  of  these  interfaces. 
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SECTION  7 


DESCRIPTION  OF  APPENDIX  A  AND  APPENDIX  B 


7.1  Appencix  A  •  Issues  and  fliiirtan«>  The  purpose  of  this  appendix  is  to  provide  practicai 
guidance  for  implementors  of  MIL-STD-1760  in  future  aircraft  and  stores.  The  guidance  is 
provided  l>y  identHymg  many  generic  issues  associated  with  implementing  the  standard  within 
the  aircraft  avionics  environment. 


7.2  Appendix  B  -  Rationale  ter  Appendix  A  This  appendix  has  been  prepared  to  provide  the 
rationale  for  sections  7-13  of  Apperxfix  A.  The  rationale  is  therefore  available,  should  it  be 
required,  without  complicating  the  ISSUE/GUIOANCE  format  of  Appendix  A. 
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MIL-STD-1760  APPLICATION  GUIDELINES 


APPENDIX  A 


Issues  and  Guidance 
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1.  INTRODUCTION 


1.1  Purpose  The  purpose  of  this  Appendix  is  to  provide  practical  guidance  for  implementors  of 
MIL-STO-1760  in  future  aircraft  applications.  This  document  identifies  and  explains  those 
issues  which  are  associated  with  implementing  the  standard  within  the  aircraft  avionic 
environment.  Although  each  particular  implementation  of  the  standard  will  require  aspects  that 
may  be  unique  to  the  application,  there  are  many  issues  which  are  generic  to  most.  The  issues 
considered  in  this  document  have  been  derived  from  specific  implementation  examples,  but  are 
presented  in  such  a  way  as  to  have  general  application.  For  each  of  the  issues  presented, 
recommended  guidance  (based  on  experience)  is  given  for  its  practical  implementation  in  a 
system  environment.  This  document  will  assist  in  the  process  of  ensuring  that  a  coordinated 
approach  to  the  application  of  MIL-STD-1760  by  the  Air  Force,  Army,  and  Navy  is  achieved. 

1 .2  Scope  The  information  contained  in  this  document  is  intended  to  provide  the  implementor  of 
the  Aircraft/Store  Electrical  Interconnection  System  (AElS),  defined  by  MIL-STD-1760,  with 
the  following: 

a  An  understanding  of  the  purpose  and  projected  benefits  of  the  standard 

b.  An  understanding  of  the  standard  itself,  including  the  electrical  signal  set,  physical 
connector  characteristics,  and  logical  design  definition 

c.  An  understanding  of  the  MIL-STD-1760  Application  Process 

d.  A  comprehensive  list  of  implementation  issues,  or  problems  to  be  resolved,  during 
the  application  process 

e.  Application  guidelines  for  each  implementation  issue,  which  may  contain  specific 
recommendations 

This  document  is  intended  to  be  available  for  use  by  all  Government  Agencies,  industrial 
organizations  and  procurement,  design,  installation  and  support  organizations. 

1.3  Limitations  Aspects  Of  aircraft/store  integration  not  considered  ir^  this  document  are 
aircraft  and  store  mechanical  compatibility  issues,  including  aerodynamic  loads  and  clearances. 
The  definition  of  MIL-STO-1760  is  as  defined  in  paragraph  2.3.  Subsequent  issues  and  notices 
of  the  standard  are  not  considered. 

1 .4  Appendix  Structure  The  overall  Structure  and  paragraph  definitions  of  the  document  are 
shown  in  figure  1.1.  Sections  7  through  13  comprise  the  main  body  of  the  document,  and  include 
groups  of  issues  and  associated  application  guidelines.  It  is  anticipated  that  the  reader  of  this 
document  will  normally  wish  to  use  it  as  a  reference  document  by  seeking  application  guidance  on 
a  specific  issue  or  issues.  Issues  may  be  referenced  by  one  of  two  routes  via  the  index  in  section 
14:  a  MIL-STD-1760  paragraph  number  or  a  specific  issue  title. 
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1.  Scope 

•  Purpose,  Scope  and  Structure  of  this  Appendix 


2.  Referenced  Documents 
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4.  Purpose,  Goals  and  Projected  Benefits  of  MIL-STD-176 

•  NATO  Interoperability 

•  System,  Hardware,  Software  and  Operational  Benefits 


5.  Description  of  MIL-STD-1760 
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-  Physical  Connector 
•  Logical  Design  Definition  (LDD' 


6.  The  MIL-STD>1760  Implementation  Process 

•  Description  of  the  Process 

•  Implementation  Phases 
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•  Installation 
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MIL-STD-1760  /  and  vice-versa. 


108 


2.  REFERENCED  DOCUMENTS 


2.1  Government  Documents  Unless  otherwise  spedHed  in  paragraph  2.3,  the  following 
specifications,  standards,  and  handbooks,  form  a  part  of  this  document  to  the  extent  specified 
herein. 


MIL-STD-454 


MIL-STD-461 


MIL-STD-462 


MIL-STO-704D 


Standard  General  Requirements  for  Electronic  Equipment 
Electromagnetic  Interference  Characteristics  Requirements  for  Equipment 
Electromagnetic  Interference  Characteristics,  Measurement  of 
Aircraft  Electrical  Power  Characteristics 


MIL-STD-882A  Safety  Program  for  System  and  Subsystem  and  Equipment,  Requirements  for 
MIL-STD-1 5536  Airaaft  Internal  Time  Division  Command  Response  Multiplex  Data  Bus 

MIL-STD-1760  Aircraft/Store  Electrical  Interconnection  System 

MIL-STO-1815A  Ada  Programming  Language 

DOD-STD-2167  Defense  System  Software  Development 


MIL-E-5400 


General  Equipment  Environment 


MIL-C-38999  Connector,  Electrical.  Circular.  Miniature.  High  Density.  Quick 
Disconnect  (Bayonet,  Threaded,  and  Breech  Coupling),  Environment  Resistant,  Removable  Crimp 
and  Hermetic  ^Ider  Contacts,  General  Specification  tor 

2.1.3  Handbooks 

MIL-HDBK-244  Aircraft- Store  Integration 


ST AN  AG  3350  AVS  Monochrome  Video  Standard  for  Aircraft  System  Applications 


DRAFT 

MIL-STD-1  760A 
(April  1985) 

DRAFT  Notice  1 
to 

MIL-STD-1  760A 
(June  1985) 


Aircratt/Store  Electrical  Interconnection  System  (Draft  for  Comment) 


Logical  Requirements 
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2.2  Contractor  Documents 


CORL'  COOK  Type  A  System  Specification  (for  an  AEIS  Implementation  System)  July  1983 
(Reference  CDC  181-02-01) 


CORL  COOL  Generic  SMS  System  Design  B1  Specification  (Reference  CDC  181-04-02) 


1 82-51 
1 82-60 
1 82-60 
1 82-60 
1 82-60 
1 82-60 
1 82-60 
1 82-60 
182-60 
1 82-60 
1 82-70 
1 82-70 
1 82-70 
1 82-60 
1 82-60 


02  AIM-9L  Parameters 
05  PCE  B2  Specifications  (CDC) 

06  SSE  B2  Specifications  (CDC) 

07  SNE  B2  Specifications  (CDC) 

08  APS  B2  Specifications  (CDC) 

09  CSE  B2  Specifications  (CDC) 

10  DC  B2  Sp^fications  (CDC) 

1 1  MFD  B2  Specifications  (CDC) 

1 2  SU  B2  Specifications  (CDC) 

21  Aircraft  Wiring  (CDC) 

07  MIL  STD-1760  Evaluation  Plan  (CDC) 
06  AVS  Evaluation  Plan 

1 3  LOD  Evaluation  Plan  (CDC) 

1 2  PCE  B2  Specifications  (CDC) 

22  MIL-STD-1760  Impact  of  Changes 


2.3  MIL-STD-176P  For  the  purposes  of  this  document,  MIL-STD-1760  shall  be  defined  as 
April  1985  draft  MIL  STO-1760A.  as  amended  by  June  1985  DRAFT  Notice  1  as  limited  by 
document  182-60-22.  References  to  the  above  Notice  1  as  compared  with  Notices  2  (Oct  86) 
and  3  (Jan  87).  have  been  included  where  it  is  felt  that  this  would  be  useful.  However,  it  was 
beyond  the  scope  of  this  effort  to  provide  more  than  minimal  coverage. 
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3.  DEFINITION  OF  TERMS 


3.1  Definition  and  use  of  terms  Terms  used  within  this  docurrtent  are  as  defined  in  the 
referenced  documents.  MIL  MOBK-244.  and  the  NATO  Glossary  of  Terms  and  Definitions  for 
Military  Use,  and  as  listed  in  Section  3  of  the  Report. 

3.2  Definition  of  acronyms  The  following  acronyms  used  in  these  Application  Guidelines  are 
defined  as  follows: 


A.  Amp 

a2|2 

AAM 

NO 

AC.ac 

A/C 

ADC 

AEIS 

AFB 

AFR 

AGM 

AFRS 

AIM 

AIS 

ALCM 

ALWT 

AM 

AMAC 

AMRAAM 

ARM 

ASCU 

ASAIAA 

ASAT 

ASDI 

ASI 

ASPJ 

ASW 

AVS 

A/W 


Ampere 

Aircraft  Armament  Interoperable  Interface 

Air-to-Air  Missile 

Air-to-Air  Override 

Alternating  Current 

Aircraft 

Air  Data  Computer 

Aircraft/Store  Electrical  Interconnection  System 

Air  Force  Base 

Air  Force  Regulation 

Air-to*Ground  Missile 

Attitude  and  Heading  Reference  System 

Air  Intercept  Missile 

AEIS  Implementation  System 

Air  Launched  Cruise  Missile 

Advanced  Light  Weight  Torpedo 

Amplitude  Modulation 

Aircraft  Monitor  and  Control 

Advanced  Medium  Range  Air-to-Air  Missile 

Anti- Radiation  Missile 

Avionics  Simulator  and  Control  Unit 

Advanced  Strategic  Air  Launched  Missile 

Anti-Satellite 

Alternate  Serial  Digital  Interface 
Aircraft  Station  Interface 
Advanced  Self-Protection  Jammer 
Anti-Submarine  Warfare 
AEIS  Validation  System 
Aircraft  Wiring 


BC  Bus  Controller 

Bit  Binary  Digit 

BIT  Built-in-Test 

BITE  Built-in-Test  Equipment 

BPS  Bits  Per  Second 

BSGT  Boresight 

BW  Bandwidth 

C8U  Cluster  Bomb  Unit 

CDR  Critical  Data  Review 

CJ  Combat  Jettison 

CRT  Cathode  Ray  Tube 

CSI  Carnage  Store  Interface 

CSSi  Carriage  Store  Station  Interface 
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t>efe<»ive  Aids  System 
Direct  Current 

Electronic  Countermeasures 
Electro-Explosive  Device 
Emerger>cy  Jettison 
Electromagnetic 
Electromagnetic  Compatibility 
Electromagnetic  Interference 
Electromagnetic  Pulse 
Electro-explosive  Release  Unit 
Existirtg  Store  Equipment 
Existing  Store  Interface 

Fire  Control  Computer 
Flight  Control  System 
Fault  Detection  Diagnostics 
Frequency  Division  Multiplexing 
Forward  Looking  Infra-red 
Frequency  Modulation 
Field  of  View 

Gravity 

Ground 

Global  Positioning  System 
Giga  Hertz 

Gi^nd  Support  Equipment 

HB  High  Bandwidth 
High  Frequency 
High-Order  Language 
High  Speed  Data  Bus 
Head-up  Display 
Hyper  Velocity  Missile 
Hertz 

Interferertce  Blanking  Unit 
Interruptive  BIT 
Identification 

Identification,  Friend  or  Foe 
Imaging  Infra-Red 
Inertial  Navigation  Equ^)ment 
Inertial  Navigation  System 
Initial  Operating  Capability 
Instruction  Set  Architecture 
Input/Output 
Input 

In  Fight  Operable  Lock 
Inierface  Consol  Document 
Infra-red 

Infra-red  Lkte  Scan 
Join  Test  Assert^ 


JTIDG 

kg 

kHz 

LAD 

LANTIRN 
'-AT.  lat 
LB 
LDD 
LLTV 

LONG,  long 

ITS 

LRSOM 

LRU 

LSP 


m 

m 

max 

MAS 

MOW 

MFCO 

MCOS 

MIL-STD 

min 

Mips 

MRASM 

MSER 

MSOW 

MSP 

MSI 

MTBD 

MTBF 

MTTR 

MTTT 

MUX 

NA 

NFV 

No. 

NSSI 

NWC 

0/6 

PAL 

PC8 

PCE 

PDU 

P-P 

Ph 


Joint  Tactical  Information  Distribution  System 

kilograms 

kilo-hertz 

Low  Altitude  Dispenser 

Low  Altitude  Navigation  and  Targeting  Infra-red  for  Night 

Latitude 

Low  Bandwidth 

Logical  Design  Definition 

Low  Light  Television 

Longitude 

Line  of  Sight 

Long  Range  Stand  Off  Missile 
Line  Replaceable  Unit 
Least  Significant  Part 

Meter 

milli  (prefix  factor  equal  to  10*3) 

Maximum 

Master  Armament  Switch 

Maneuvering  Cluster  Weapon 

Multiple  Ejector  Rack 

Multi- Function  Controls  and  Displays 

Multifunctional  Infrared  Coherent  Optical  System 

Military  Standard 

Minimum  or  Minute 

Million  Instructions  per  Second 

Medium  Rango  Air-to-Surface  Missile 

Multiple  Store  Ejector  Rack 

Modular  Stand  Off  Weapon 

Most  Significant  Part 

Mission  Store  Interface 

Mean  Time  Between  Defects 

Mean  Time  Between  Failures 

Mean  Time  to  Repair 

Mean  Time  Tc  Test 

Multiplex 

Not  Applicable 
Narrow  Field  of  View 
Number 

Non-Standard  Store  interface 
Naval  Weapons  Center 

Outboard 

Permissive  Action  Link 
Printed  Circuit  Board 
Process  Control  Equipment 
Power  Distribution  Unit 
Peak-to-Peak 
Phase 


M3 


PSJ 

Pilots  Selective  Jettison 

Q\ 

Quality  Assurance 

RF 

Radio  Frequency 

REF 

Reference 

RET 

Return 

RIU 

Remote  Interface  Unit 

RFI 

Radio  Frequency  Interference 

RPV 

Remotely  Piloted  Vehicle 

RS 

Radiated  Susceptibility 

RT 

Remote  Terminal 

RTN 

Return 

S 

Second(s) 

SAIR 

Safe  and  In- Range 

SAM 

Surface-to-Air  Missile 

S&RE 

Suspension  and  Release  Equipment 

SEAM 

SRAAM/Sidewinder  Expanded  Acquisitbn  Mode 

sec 

Second 

SEL 

Select,  Selected 

SS^ 

Standard  Electronic  Module 

SEMP 

Standard  Electronic  Module  Program 

SJ 

Selective  Jettison 

SMS 

Stores  Management  System 

SISF 

Signal  to  Noise  Ratio 

SOW 

Statement  of  Work 

SPJP 

Self- Protection  Jammer  Pod 

SRAM 

Short  Range  Attack  Missile 

SRU 

Shop  Replaceable  Unit 

SSI 

Standard  Store  Interface 

TBD 

To  Be  Determined 

TCM 

TEROOM 

TCP 

Time  Correlation  Pulse 

TCS 

TACAN 

TER 

Triple  Ejection  Rack 

TFR 

Terrain  Following  Radar 

TGT 

Target 

KM 

Tube  Launched  Optically  T  acked  Wire  Guided 

TRIG 

TRK3GER 

TV 

Television 

TXR(S) 

Transformer(s) 

u 

micro  (prefix  factor  equal  to  10*^) 

UHF 

Ultra  High-Frequency 

USAF 

United  States  Air  Force 

[N 

Ultra-Violet 

UW 

Under  Water 

V 

Volts 

\A 

Volt  Amps 

WfiC 

Volts  Alternating  Current 
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WASP 

V\CS 

WFV 

WRIS 

WRT 


Verify  Control  Word 
Velocity 

Volts  Direct  Current 
Very  High  Frequency 
Video  Tape  Recorder 

Wide  Area  Special  Projectiles 
Weapon  Control  System 
Wide  Field-of>View 
Weapon  Release  Inventory  Switch 
With  Respect  To 


4.  PURPOSE.  GOALS  AND  PROJECTED  BENEFITS  OF  MIL-STD-1760 


Paragraphs  4.i  through  4.6  discuss  the  purpose,  goals,  and  projected  benefits  of 
MIL-STD-1760  while  4.7  discusses  future  control  of  the  standard  to  maintain  its  credibility. 

4.1  Current  lack  of  Interoperahilitv  Within  NATO  countries,  other  than  the  US.  aircraft  are 
purchased  to  support  specific  missions,  for  example  fighter  or  ground  attack,  and  furthermore 
they  tend  only  to  purchase  one  type  of  aircraft  for  each  mission.  Also,  unfortunately,  in  order  to 
‘keep  an  independent  capability,'  many  NATO  countries  also  have  different  types  of  aircraft 
between  them  to  support  the  same  basic  missions.  In  both  the  US  and  NATO,  stores  are  developed 
largely  independent  of  each  other,  even  though  the  requirements  may  be  very  similar,  and  within 
NATO,  mainly  due  to  the  earlier  discussion,  they  quite  often  support  only  one  type  of  aircraft. 
This  quite  absurd  situation  has  resulted  in  unique  aircraft/store  electrical  interconnection 
requirements  and  a  consequent  proliferation  of  interface  designs.  Table  4.1  gives  some  examples 
of  this.  This  lack  of  standardization  has  led  to  low  levels  of  interoperability  which  have  a 
detrimental  impact  on  force  effectiveness.  Technology  advances  have  led  to  a  quarium  jump  In 
the  requirements  of  effectiveness  (in  both  capability  and  flexibility)  of  mission  stores  and  have 
also  meant  that  the  age  old  requirements  to  stand-off  from  the  target  is  now  a  practical 
proposition.  This  is  now  being  reflected  into  the  use  of  increasing  amounts  of  avionic  data  and 
control  information  from  aircraft  systems  and  this,  if  allowed  to  proceed  without  a  common 
interface  standard,  for  example  MIL-STO-1553B  is  required  by  MIL-STD-1760,  will 
inevitably  lead  to  insurmountable  technical  and  or  funding  problems. 

Table  4.1  Example  of  Aircraft,  Stores,  and  Store  Missions 


Aircraft 

Store 

Store  Mission 

F4  M 

Sparrow 

MRAAM  (Radar) 

TORNADO  ADV 

Sky  Flash 

MRAAM  (Radar) 

ORION 

Harpoon 

Anti-Ship  Missile 

SEA  HARRIER 

SeaEaoie 

Anti-Ship  Missile 

TORNADO  FRG 

Kormoran 

Anti-Ship  Missile 

USAF 

AIM-9J/P 

SRAAM 

USN 

AIM-9L/M 

SRAAM 

TORNADO  UK 

AIM-9L 

SRAAM 

TORNADO  FRG 

AIM-9L 

SRAAM 

USAF 

UXLPOO 

Area  Denial 

TORNADO  UK 

JP  233 

Area  Denial 

TORNADO  FRG 

MW1 

Area  Denial 

Note;  France  has  an  equivalent  for  each  one  of  the  stores  listed  above,  for  example  anti-ship  is 
Exocet,  and  these  also  have  different  interfaces. 


4.2  Purtx)se  and  Goals  of  MIL-STD-1760  The  application  of  this  standard  to  new  and  existing 
aircraft  and  to  new  stores  will  significantly  reduce  and  stabilize  the  number  and  variety  of 
signals  required  at  aircraft/store  interfaces.  This  will  minimize  the  cost  impact  of  new  stores 
on  future  stores  management  systems,  and  increase  store  interoperability  among  the  services, 
within  NATO  and  with  our  other  allies.  In  practice,  true  interoperability  will  not  be  fully 
achieved,  but  a  significant  reduction  in  the  support  costs  will  accrue.  It  is  important  to 
understand  that  the  goal  of  interoperability  does  not  mean  the  standardization  of  all  stores  or 
aircraft  systems  per  se.  However,  it  should  mean  all  NATO  aircraft  should  be  able  to  carry,  and 
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employ,  the  NATO  stores  specific  to  that  aircraft  mission,  as  well  as  the  national  specific 
solution  with  minimal,  or  preferably  no.  modifications. 

4.3  Benefits  of  MIL-STD-176Q  fGeneralt  The  perceived  benefits  are  increased 
interoperability  of  aircraft  stores  and  decreased  aircraft-store  integration  time  and  cost.  Some 
aircraft  system  designers  argue,  however,  that  the  electrical  integration  costs  are 
inconsequential  when  compared  to  the  physical  integration  problem,  and  that  the  standard  will 
not  provide  interoperability.  The  costs  of  physical  integration  are  not  pertinent  to  the  MIL- 
STD-1760  issue.  The  fact  remains  that  millions  of  dollars  are  wasted  on  unnecessarily  complex 
electrical  integration  tasks.  This  problem  may  increase  dramatically  as  the  sophistication  and 
electrical  complexity  of  stores  increase.  MIL-STD-1760  alone  will  not  provide  electrical 
interoperability  of  various  store  types.  If,  however,  interoperability  is  evaluated  in  terms  cf 
cost  of  integrating  new  stores,  and,  if  the  services  make  and  stand  by  a  decision  that  all  new 
stores  will  be  MIL-STD-1760  stores,  then  a  quantitative  measure  of  the  benefits  of  the  standard 
is  available. 

4.4  The  Benefits  of  the  MIL-STD-1760  Logical  Design  Definition  fLDDI  A  workaple  logical 
definition  for  aircraft-to-store  interfaces  can  dramatically  facilitate  the  integration  of  new 
stores  on  an  aircraft  and  enhance  the  interoperability  of  a  single  store  on  different  aircraft. 
However,  the  LDD  is  widely  believed  to  increase  the  store  and  aircraft  processing  requirements. 
In  some  quarters,  this  is  seen  as  increasing  software  and  processing  requirements  of  both  the 
store  and  the  aircraft  armament  system.  Howe'  "'*’,  this  is  far  from  the  case  as  the  example  of  the 
integration  of  AIM-120  onto  the  F-16  illustrated,  where  this  integration  caused  a  change  of  the 
inertial  co-ordinate  definition  used  on  the  F-16  avionics.  This  has  now  become  the  de  facto 
standard  within  MIL-STD-1760A  Notice  3.  which  means  that  any  future  SSI  store  requiring  this 
function  must  use  the  "standard*  way  and  at  least  both  F-IS  and  F.16,  which  are  both  AIM-120 
iniegraied,  will  also  be  compatible.  On  the  store  side  of  the  interface,  the  need  to  accommodate 
the  1 553B  word  and  message  lengths  has  also  been  an  issue,  that  is  why  not  allow,  say,  4  bits  of 
X  length  transmitted  as  1  word  every  y  milliseconds  or  h  length  transmitted  as  2  words  every  y 
milliseconds  or  x  length  transmitted  as  4  "words"  every  I  microseconds?  The  cost  and  time 
associated  with  integrating  a  new  store  on  existing  aircraft  or  fielding  a  new  aircraft  capable  of 
interface  with  a  wide  variety  of  unique  store  interfaces  outweighs  any  extra  effort  or  costs 
involved  with  adherence  to  the  standard.  Bus  transceivers,  decoders,  and  memory  elements  are 
dropping  in  price  at  a  dramatic  pace.  The  same  applies  to  the  CPU  and  other  processing  elements 
residing  within  the  store.  Other  than  price,  capability  must  be  considered.  The  ultimate 
capability  provided  by  imptementing  interfaces  meeting  the  standard  will  certainly  be  higher 
and  more  easily  achieved  than  is  presently  the  case  in  the  weapon  community.  Rarely  has  an 
increase  in  weapon  capability  been  easily  or  cheaply  attained.  If  adherence  to  the  logical  design 
requirements  provides  a  store  or  aircraft  with  unused  capability  for  future  enhancements,  then 
it  appears  a  good  investment.  A  final  point  to  conr-der  is  that  once  a  weapon  system  such  as  the 
F-16  is  capable  of  meeting  a  sophisticated  store’s  requirements  (AIM-120A.  for  example), 
much  of  the  software  and  ocntrol  capability  can  be  applied  relatively  cheaply  to  later  weapons. 
The  AIM-120A  transfer  alignment,  targeting,  and  initialization  schemes  might  easily  be  adapted 
for  future  weapons  with  similar  requirements,  rather  than  developing  new  and  unique  software 
modules  for  each  new  weapon.  The  MIL-STD-1760  Logical  Design  Definition  should  therefore  be 
used  as  agreed  to  and  published.  If  the  interface  requirements  of  the  store  are  relatively 
insignificant  compared  to  the  capabilities  provided  by  the  standards  bus  and  logical  definition, 
advise  the  procuring  agency  of  the  cost  disadvantage  and  seek  guidance  on  using  the  Low 
Bandwidth  alternate  (currently  under  review)  or  accept  the  apparent  cost  disparity. 

4.5  Extra  Bus  Usage  Imposed  bv  the  LDD  Adoption  of  MIL-STD-1760  and  its  logical  design 
definition  has  generated  concern  regarding  data  bus  usage.  A  general  feeling  exists  that  bus 
loading  will  increase,  possibly  to  unacceptable  levels,  with  strict  adherence  to  the  standard.  The 
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basic  protocols  of  MIL-STD-1553  tend  to  drive  the  overall  bus  usage,  not  the  demands  of  the 
MIL-STD-1760  logical  design  definition.  Secondly,  aircraft  stores  management  system 
architectures  can  have  as  great  or  greater  impact  upon  bus  usage  than  either  MIL-STD-1553B 
or  MIL-STD-1760  requirements.  For  example,  an  aircraft  with  station  encoder-decoders 
(F  18).  or  remote  interface  units  on  the  weapons  bus  (F-16),  as  well  as  stores,  will  generally 
use  more  of  that  bus's  capacity  than  an  aircraft  with  only  stores  and  the  bus  controller 
(F-15C/0)  on  its  armaments  bus.  In  other  words,  given  an  identical  store  load,  one  aircraft 
will  be  using  some  of  its  bus  capacity  for  communications  above  and  beyond  those  required  for 
the  stores,  and  the  other  will  not.  A  final  point  relates  bus  loading  to  mission  phase.  The 
greatest  load  on  the  bus  occurs  during  the  Store  Description  transfer  between  the  store  and 
central  processor(s)  or  other  stores.  Typically,  this  occurs  shortly  after  system  or  weapon 
initialization  when  time  is  not  as  critical  as  it  is  immediately  prior  to  release/launch.  Bus 
designs  should  therefore  be  implem‘'nted  that  reduce  non-store  addresses  and  take  advantage  of 
the  standardized  formats,  messages,  and  data  entities  put  forth  by  the  standard. 

4.6  Projected  Benefits  of  MIL-STD-176Q 

4.6.1  Operational  Benefits  These  benefits  arise  primarily  from  two  sources:  Interoperability 
and  Damage  Tolerance.  As  indicated  earlier,  operational  effectiveness  must  be  impaired  by  the 
inability  to  cross  operate  stores  across  specific  aircraft  within,  say,  the  US  Air  Force  or 
between  the  US  Air  Force  and  US  Navy  or  between  either  and  NATO,  be  the  latter  Air  Force  or 
Navy.  In  times  of  conflict,  the  provisioning  of  stores  at  strategic  locations  able  to  cope  with  the 
variations  in  requirements,  air  to  air  or  air  to  ground  or  air  to  ship,  must  be  a  costly  logistics 
nightmare  and  certainly  beyond  the  scope  of  most  NATO  countries.  It  must  therefore  bo  of 
immense  value  to  be  able  to  design  stores  which  physically  (connectors  and  wiring)  arc 
interoperable.  In  terms  of  data  availability  and  the  appropriate  software  ‘control,*  it  will 
probably  be  some  years  before  interoperability  can  be  achieved.  However,  there  is  no  .'eason 
why  aircraft  could  not  carry  the  appropriate  control  algorithms  on  a  permanent  ‘just  in  case* 
basis,  providing  the  appropriate  data  is  available  from  the  prime  sensors,  rurthermore.  it  may 
be  possible  to  employ  a  store  in  a  useful,  but  degraded  mode,  where  other  more  effective 
alternative-.'  are  out  of  stock.  The  advent  of  digital  communication  between  stores  and  aircraft 
also  means  that  a  lot  more  inferm^tion  can  be  made  available  regarding  damage,  be  it  battle  or 
failure,  enabling  the  aircraft  to  utili.re  degraded  operation  modes  as  applicable.  It  should  also  be 
possible  for  other  aircraft  equipments,  either  duplicated  SMS  hardware  (even  distributed 
processing  within  the  SMS  LRUs)  O'^  non  SMS  equipment  to  assume  a  processing  role.  Of  course 
in  the  latter  case  access  to  the  multiplex  bus  would  be  required  and  with  the  probable  exclusion 
of  Arming  and  Release  functions.  Many  current  stores  have  no  means  of  indicating  that  all  analog 
signals  transmitted  from  the  aircraft  have  indeed  arrived.  This  means  that  no  indication  of 
capability  or  serviceability  is  available  and  furthermore,  even  it  they  did  arrK-e,  vhether  the 
store  is  uiilizing  them  correctly.  The  advent  of  the  multiplex  data  bus  should  alleviate  this 
problem.  Additionally,  the  fact  that  the  Multiplex  Data  Bus  is  redundant  should  have  significant 
benefit  against  cable  faults,  battle  damage  or  otherwise  and,  providing  duplication  has  been 
provisioned,  bus  controller  failure,  battle  damage  or  otherwise. 

4.6.2  Physical  Benefits 

a  Same  connector(s)  used  for  SSI  stores 

b.  Same  LRU  hardware  used  for  SSI  stores 

c.  Same  A/C  wiring  used  for  SSI  stores 

d.  Connector  at  ASI  can  possibly  be  used  for  existing  store  control 

e.  No  increase  in  aircra't  wiring  or  LRU  hardware  increase  affecting  aircraft  weight 
(Note:  the  Increase  in  weight  due  to  software  update  is  not  considered  significant) 
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a  Generic  system  solutions 

b.  Generic  system  design  for  implementing  MIL-STO-1760A 

-  clearly  defined  interfaces  between  SMS  equipments 

-  simple  SMS  design  provides  high  mission  success  via  reoonfigurable 

interfaces 

-  reduced  aircraft/store  integration  effort 

c.  Reduced  Integration  Cost 

-  minimized  systems  modifications 

-  minimized  documentation  changes 

-  distributed  processing  enabled 

d  Reduced  Integration  Time 

•  minimized  systems  modifications 

-  reduced  software  QA  problems 

\}.  Safety  Maintained 

-  standard  secure  formats 

•  restrictions  on  interface  formats 

4.6.4  Eouipne^l  Benefits 

a  Ccmnion  hardware  capability  for  AIS 

•  reuse  of  proven  designs 

b.  Common  AIS  interface  to  Armament  Bus  and  Stores  gives  reduced  integration  effort 
and  oost 

•  ability  to  optimize  hardware 

•  increased  intervals  between  upgrades 

4.6.5  Software  Benefits 

a  Transportable/Reuseable  software  due  to  MIL-STD-1760  Logical  Design  Definition 

b.  Better  documentation  and  configuration  control  using  high  order  languages 

c.  Reduced  size  of  Software  updates 
d  Program  code  size 

e.  Reduces  oost  of  successive  Software  validation  exercises. 

f.  Performance  improved 

-  reduced  requirement  tor  reformatting 

•  ability  to  implement  some  protocol  in  hardware  thereby  reducing 
software  execution  requirements 

4.7  Proposed  MIL-STD-176Q  Control  Board  MIL'STD-1760  is  relevant  to  all  three  US 
services  and  NATO.  At  present,  however,  the  standard  is  being  managed  by  the  OPRs  aided  b/  the 
SAE.  There  is  no  recognized  multi-service  forum  for  resolving  MIL-STD-1760  issues.  This 
has  resulted  in  significant  delays  in  publication  of  the  standard  and  can  ultimately  result  in  its 
being  ignored  by  services  or  organizations  within  services.  Several  suggestions  have  been  made 
for  multi-service  (plus  NATO  and  DOE)  MIL-STD-1760  Control  Boards  with  industry 
participation  as  non-voting  members.  Any  one  of  these  suggestions  would  work.  Two  examples 
of  standards  with  multi-service  control  boards  are  MIL-STD-1553  and  MIL-STD-1750. 
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5.  OVERVIEW  OF  MIL-STO-1760A 


This  section  gives  a  short  oven/iew  of  MIL-STD-1760A  up  to  and  including  Notice  3. 

5.1  Introduction  to  MIL-STD-176QA  MIL-STD-1760A  is  a'.  Aircraft  to  Store  electrical 
interconnection  system  designed  to  cover  ail  the  foreseeable  ;20-t-years)  electrical  and  optical, 
requirements  for  stores  and  their  carrying  aircraft.  It  stems  from  the  need  to  minimize  the 
numbers  of  wires,  with  the  consequent  quantity  and  variety  of  connectors,  and  to  digitize  the 
current  analog,  not  including  RF  and  Video,  signals  that  stores  and  aircraft  require. 

5.1.1  Interfaces  Four  interfaces  are  defined  in  the  standard  and  are  listed  below.  These 
interfaces  are  designed  to  cater  for  the  carriage  of  a  store  on  an  aircraft  with  indirect  or  direct 
electrical  connections,  that  is  with  or  without  a  carriage  store.  The  interfaces  are  shown  fully, 
with  a  variety  of  typical  configurations,  in  figure  5.1. 

Aircraft  Station  Interface 
Mission  Store  Interface 
Caniage  Store  Interface 
Carriage  Store  Station  Interface 

5.1.2  Elements  of  the  Interface  There  are  three  hierarchical  elements  in  the  interface  which 
are  covered  by  the  standard.  The  Electrical  element  concerns  the  signal  set;  the  Logical  concerns 
the  communications  architecture,  message  content  and  formatting,  and  data  transfer  protocol; 
and  the  Physical  concerns  the  connectors  and  contacts. 

5. 1.2.1  Electrical  The  electrical  element  is  limited  by  defining  41  contacts  and  the  signals 
which  they  are  allowed  to  support.  These  signals  are  distributed  across  two  connectors,  the 
Primary  Interface  Signal  Set  connector  and  the  Auxiliary  Power  Signal  Set  connector.  The 
signals  that  make  up  these  sets  are  showri  in  figure  5.1. 

5.1. 2.2  Logical  This  element  is  chiefly  concerned  wit''  the  data  flow  across  the  Multiplex  Data 
Bus  interface.  A  breakdown  of  the  prime  areas  of  data  flow  is  given  in  Paragraph  5.4. 

5.1. 2.3  Physical  This  element  concerns  the  connectors.  These  are  MIL-C-38999  Series  III 
shells  using  specific  inserts,  designed  to  support  MIL  STD-1760A.  which  are  now  included  in 
MIL-STD-1560A.  The  contacts  are  standard  MIL  C-39029  contacts  including  two  50  ohm  co¬ 
axial  contacts  which  have  been  specifically  designed  for  co-axial  cable  applications  (new  Slash 
Sheets  102  and  103). 

5.1 .3  Classns  During  the  development  period  it  was  found  to  be  expeditious  to  allow  two  classes 
of  primary  interface  to  which  the  auxiliary  could  be  added.  This  should  enable  a  store 
specification  to  indicate  which  class  is  available,  across  its  interoperable  range  of  aircraft,  for 
it  to  interface  with. 

5.2  Summary  of  signal  sets  There  are  two  signal  sets,  namely  the  primary  interface  signal  set 
and  the  auxiliary  power  signal  set  and  these  are  shown  in  figure  5.2.  Four  classes  of  interfaces 
have  been  specified  from  these  two  signal  sets: 

Class  I  -  Full  primary  interface  signal  set 
Class  lA  -  Class  I  plus  the  auxiliary  power  signal  set 

Class  II  •  Class  I  minus  HB2  and  4  and  both  the  Fiber  Optic  and  270V  DC  provisions 
Class  ilA  -  Class  II  plus  the  auxiliary  power  signal  set 
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STRUCTURE  GROUND 


FIGURE  5.2  MIL-STD-1760  Signal  Set 


122 


PROV»ION  ONLY 

NOT  USED  M  CLASS  II  INTERFACE 


5.2.1  Pfimary  Interfaca  Signal  Set  The  primary  interface  signal  set  is  composed  of  interfaces 
for  both  high  and  low  bandwidth  signals,  digital  multiplex  data  bus  signals,  a  specified  number  of 
dedicated  'discrete*  signals,  current  aircraft  power  and  growth  for  Fiber  Optics  and  270V  DC 
power.  Each  of  these  interfaces  is  discussed  more  fully  bebw: 

5.2.1 .1  Hioh  Bandwidth  Interfaces  There  are  four  interfaces  for  transferring  two  types  of 
signals.  The  aircraft  is  responsible  for  controlling,  assigning  and  routing  the  Type  A  and  Type  B 
signals  to  their  proper  destinations  on  the  appropriate  high  bandwidth  line.  These  lines 
(HB1,HB2,HB3  and  HB4)  have  the  capability  to  be  interconnected,  by  the  aircraft,  for  ASI  to  ASI 
and  ASI  to  Aircraft  bi-directional  data  transfers.  A  Summary  of  their  chief  characteristics  is  as 
follows: 

a 

b. 

c. 


d. 


e. 


Type  A  signals: 

Type  B  signal: 

HB1: 

HB2: 

HB3  and  HB4: 

HB1  (Type  B): 

HB1  (Type  A)  and  HB2 


20  Hz  to  20  MHz  -  Between  ASI  and  Aircraft  and  between  ASI  and  ASI 
20  MHz  to  1 .6  GHz  -  Between  ASI  and  aircraft  only 
Type  A  or  Type  B  @>  50  ohm  impedance 
Type  A  (g>  50  ohm  impedance 
Type  A  (§>  75  ohm  impedance 
RF 

time  correlation  signals 


HB3  and  HB4:  video 
HB1  and  HB2  return  is  grounded:  HB3  and  HB4  return  is  isolated 


5.2. 1.2  Low  Bandwidth  Interface  This  interface  is  capable  of  transferring  low  bandwidth  (DC  to 
50  kHz)  signals  in  both  directions  between  the  aircraft  and  stores.  At  this  time  it  is  used  only 
for  tones  arKf  voice  grade  audio  signals.  It  is  not  to  be  used  for  discrete  functions. 

5.2. 1.3  Diflilal  Multiplex  Data  Interface  Two  channels  (Mux  A  and  Mux  B)  are  provided  for 
transferring  digital  information,  such  as  store  control  and  store  status  data,  between  aircraft 
and  stores  in  a  dual  standby  redundant  mode.  These  signals  comply  with  the  requirements  of 
MIL-STO-1553B. 


5  2.1.4  Address  Interface  This  interface  is  used  to  assign  a  unique  MIL-STD-1553  remote 
terminal  address  to  the  connected  store.  It  contains  a  set  of  six  discretes  (AO  to  A4  plus  parity) 
and  one  common  address  return. 

5  2.1.5  Release  Consent  Interface  This  interface  is  a  28V  (nominal)  discrete  used  only  to 
enable  or  disable  safety  critical  store  functions  being  commanded  by  the  aircraft  over  the  Digital 
Multiplex  Data  Interface  (see  5.2. 1.3). 

5  2.1.6  Primary  Interlock  Interface  A  primary  interlock  interface  is  available  for  the  aircraft 
to  monitor  the  electrically  mated  status  of  the  Primary  Interface  connector  between  store  and 
aircraft. 

5  2.1.7  Primary  Structure  Ground  In  order  to  minimize  shock  hazards  to  personnel,  this 
connection  is  supplied  between  the  aircraft  and  store  structure.  It  is  not  used  as  a  signal  or 
normal  power  return  path,  but  may  be  used  as  an  emergency  power  return  at  10  Amps. 

5  2.1.8  Primary  26V  DC  Power  The  aircrafi  provides  28V  DC  1  for  use  on  nonsafety  critical 
store  circuits  and  28V  DC  2  for  safety  critical  circuits.  Both  are  rated  at  10  Amperes 
continuous.  In  fact  28V  DC  2  may  bo  used  for  powering  any  circuitry,  but  because  its  prime  use 
is  for  safety  critical  circuitry,  the  time  for  which  it  is  likely  to  be  available  prior  to  store 
separation  is  very  limited. 
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5.2.1. 9  Primafy  115V  AC  Power  The  airaafi  provides  one  channel  of  3  phase  1 15V  AC  lated  at 
1 0  Amperes  continuous  per  phase.  Store  designs  which  do  not  utilize  28V  DC  2  for  powering 
safety  critical  circuits  and  therefore  rely  on  voltages  internally  derived  from  the  115V  AC,  must 
design  in  appropriate  safety  interlocks  of  their  own  as  it  is  totally  impractical  for  the  aircraft  to 
supply  any  such  safeguards  with  power  availability. 

5.2.1.10  Ftoer  Qotic  Interface  The  characteristics  of  these  signals  are  not  yet  added  to  the 
standard  and  are  not  included  in  dass  II  interfaces. 

5.2.1 .1 1  Primary  27QV  DC  Power  The  characteristics  of  this  signal  is  not  yet  added  to  the 
standard  and  is  not  included  in  dass  II  interfaces. 

5.2.2  Auxiliary  Power  Signal  Set  The  auxiliary  power  signal  set  consists  of  an  interlock 
discrete,  structure  ground  and  aircraft  power. 

5.2.2. 1  Auxiliary  Interlock  Inlerface  An  auxiliary  interlock  interface  is  available  for  the 
aircraft  to  monitor  the  electrically  mated  status  of  the  Auxiliary  Interface  connector  between 
store  and  aircraft. 

5.2.2  2  Auxiliary  Structure  Ground  In  order  to  minimize  shock  hazards  to  personnel  this 
connection  is  supplied  between  the  aircraft  and  store  structure.  It  is  not  used  as  a  signal  or 
normal  power  return  path,  but  may  be  used  as  an  emergency  power  return  at  30  Amps. 

5.2.2  3  Auxiliary  28V  DC  Power  The  aircraft  provides  one  channel  of  auxiliary  28V  DC  power 
rated  at  30  Amperes  continuous.  It  is  intended  for  safety  critical  use  and  therefore  has  the  same 
’rules*  as  Primary  28V  DC  2. 

5.2.2.4  Auxiliary  115V  AC  Power  The  aircraft  provides  one  channel  of  auxiliary  115V  AC 
power  rated  at  30  Amperes  continuous  per  phase.  As  for  the  Primary  115V  AC  power,  no  power 
availability  safeguards  will  be  provided  by  the  aircraft. 

5.2.2.5  Auxiliary  270V  DC  Power  The  characteristics  of  this  signal  is  not  yet  added  to  the 
standard  and  is  not  included  in  Class  HA  interfaces. 

5.3  M1L-STD-176QA  Connectors  Types  It  is  important  to  note  that  MIL-STD-1760A  only 
specifies  that  the  connectors  being  used  must  have  intermateability  with  MiL-C-38999  design. 
This  is  to  allow  connectors  to  have  modifications,  say  a  backfitting  thread  increase,  which  do  not 
affect  intermateability.  MIL-C-38999  connectors  which  can  be  used  fall  into  three  categories 
listed  below.  In  all  cases  a  shell  size  25  is  required.  Furthermore,  there  is  no  difference  in 
these  requirements  between  primary  or  auxiliary  connectors  except  for  the  insert  arrangement. 

Fixed  sockets  -  38999  Slash  Sheet  20  or  24 

Free  plug  38999  Slash  Sheet  26 

Snatch  plug  38999  Slash  Sheet  31  (lanyard  release) 

5.3.1  Interface  Usaoe  The  three  basic  categories  cKscussed  above,  have  applicability  as  follows: 
Slash  20  or  24  (jam  nut  or  flange  mount)  can  be  used  at  the  ASI,  CSI,  CSSI  and  MSI;  Slash  26 
can  be  used  at  the  ‘top*  of  the  umbilical,  that  is  it  is  the  mating  half  for  the  ASI  and  CSSI. 
Providing  tfto  carriage  store  were  not  jettisonabie.  the  Slash  26  may  also  be  used,  on  a  special 
umbilical,  as  the  mating  half  for  the  CSI.  that  is  the  *top'  and  'bottom';  SU^  31  can  be  at 
the  'bottom*  of  the  umbilical,  that  is  it  is  the  mating  halt  for  the  CSI  and  MSI.  It  should  be  ntMed 
that,  at  this  time  no  connector  requirements  are  specified  for  the  MSI,  or  its  mating  half,  used  in 
Rail  Launch  applications. 
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5-3.2  Connector  Inserts  Two  connector  insert  arrangements  are  specified  to  fit  the  shells 
discussed  above.  These  inserts  are  for  the  Primary  and  Auxiliary  applications  ar>d  are  defined  in 
MIL-STD-1560,  arrarigements  25-20  and  25-11  respectively.  No  other  insert  arrangements 
are  authorized. 


5.3.3  Connector  Contacts  These  contacts  are  those  specified  in  MIL-C-39029  as  listed  in 
MIL-STD-1760A.  At  this  time.  MIL-STD-1760A  requires  amendment  to  add  two  contacts,  a 
mating  pair,  to  the  Primary  arrangement  list.  These  contacts.  Slash  Sheet  102  and  103,  are  the 
pin  and  socket  contacts,  respectively,  required  for  the  High  Bandwidth  1  and  2  applications.  It 
has  been  necessary  to  develop  new  contacts  which  are  specifically  designed  for  50  ohm  co-axial 
cable,  in  order  to  meet  the  stringent  VSWR  requirements  of  the  MIL-STD-1760A  High 
Bandwidth  1  installation. 

5.4  Summary  of  the  Logical  Deskin  Definition  /LDDI  The  LDD.  as  defined  in  paragraph  2.3.  has, 
of  January  1987.  been  issued  with  amendments  as  formal  notices  1.  2  and  3  to 
MIL-STD-1760A.  Their  content  is  as  follows: 

5.4.1  Notice  1:  (US  Navy  only) 

Power  Up  Sequence 

MIL-STD-1553  Subaddress  allocation 

Store  Description  message  including  weapon  identification  scheme  and  Data  Checksum  Algorithm 
(additional  to  MIL-STD-15S3) 

5.4.2  Notice  2:  (Joint  Service) 

Content  as  Notice  i 

5.4.3  Notice  3:  (Joint  Service) 

MIL-STD-1553B  Command  and  Status  Word  Requirements  (includes  further  sub-address/mode 
field  applications) 

Protocol  Execution 

Mass  Data  Transfer 

Safety  Critical  Message  Requirements 

Non-Safety  Critical  Message  Requirerrtents 

Standard  Data  Entities  (includes  standard  coordinate  systems) 

5  4.4  Logical  Design  Definition  fLDDi  Discussion  The  discussion  that  follows  considers  each 
prime  part  of  the  LDD  and  any  maior  implications  of  the  associated  requirements  are  considered. 
Major  differences  between  Draft  Notice  1  dated  3  June  1985  and  Notice  3  dated  30  January 
1987  are  noted. 


5  4.4.1  M1L  STD-1553B  Word  Reouirements 


5.4.4. 1.1  Command  Word  fB5(L1.1|  The  command  word  requirements  are  basically  those  in 
MIL-STD-1553B.  Certain  field  requirements  are  reinforced  or  mandated.  Within  the  address 
field  the  broadcast  option  is  limited  to  mode  commands.  Within  the  sub-address/mode  field  the 
following  mode  commands  are  mandated: 


a  Reset  Remote  Terminal 

b.  Transmit  Last  Command 

c.  Transmitter  Shutdown 

d.  Override  Transmitter  Shutdown 

e.  Transmit  Vector  Word 


(stores  only) 

(stores  only) 

(stores  only) 

(stores  only) 
(aircraft  and  stores) 
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f.  Syitchronize  With  Data  (aircraft  and  stores) 

g.  Transmit  Status  (stores  only) 

Further  to  this  the  follovnng  mode  commands  are  prohibited:  Dynamic  Bus  Control  and  Reserved 
Mode  Codes.  All  other  mode  commands  are  permitted  with  the  provision  that  implementation  of  a 
permitted  mode  code  by  the  aircraft  or  store  does  not  require  the  store  or  aircraft  to  reciprocate. 
Note  that  certain  permitted  mode  commands  are  required  to  be  paired.  Within  the  sub* 
address/mode  field  the  following  sub-addresses  have  been  allocated: 


a  Routing  Control/Monitor  -  03 

b.  Routed  Data  •  05 

c.  Store  Description  -  06 

dL  Nuclear  Wes^n  -  07 

e.  Test  -  08 

f.  Mission  Store  Control/Monilor  -  11 

g  Lmked  Messages  -  14 


5.4.4. 1.1.1  Notice  3  fB4Q.l.l)  There  are  no  prime  nrtode  code  differences.  Sub-address 
allocation  differences  are  as  follows: 


a 

Routing  Control/Monitor 

-  Eliminated 

b. 

Routed  Data 

•  Elim  nated 

c. 

Store  Description 

-  01 

d 

Nudear  Weapon 

-  19  and  27 

a 

Mass  Data  Transfer  (Linked  Messages) 

-  14 

5.4.4.1.2  Status  Word  (B50.1.2)  The  status  word  requirements  are  basically  those  in 
MIL-STD-1553B.  The  implementation  of  the  Service  Request,  Busy,  Sub-system  Flag,  and 
Terminal  Flag  bits  are  regulated  by  MIL-STO-1760A. 


5.4.4. 1J2.1  Noticu  3  |B4Q.1.2|  There  are  prime  differences  between  the  implementation  of  the 
following  two  bits:  Service  Request  and  Si^system  Rag. 

5.4.4  2  Protocol  Execution 


5.4.4.2.1  Protocol  Checks  fBSO.I.S.I)  Protocol  checks  are  listed  below.  The  store  is  required 
to  conduct  protocol  checks  on  a'l  receive  messages  that  can  initiate  safety  critical  actions  and 
must  do  so  within  the  allowed  busy  time.  All  other  checking  is  optional,  but  must  still  be  carried 
out  within  the  busy  time,  if  implemented. 

Veriftcation  of  Sub-address 
Verification  of  Checksum  (if  implemented) 

Verificaiion  of  Header 

Verification  of  Critical  Authority  and  Control 

5  4.4.2.1.1  Notica  3  (B4Q.1.5.1|  The  requirement  for  verification  of  sub-address  has  been 
removed  as  has  the  requirement  to  carry  out  the  remaining  checks  within  the  busy  time.  A 
'protocol  check'  failure  reporting  mechanism  has  been  included. 

5.4 .4.2.2  Chedtsum  Reffijirement  1650.1.5.2]  A  dtecksum  algorithm  (Rotatel  Mo(k^  2) 
specified  in  the  standard.  This  is  the  only  algorithm  which  may  be  used  and  its  use  te  optional 
and  determined  by  the  store.  When  implemented,  it  is  positioned  in  the  last  word  of  the  message 
and  when  not  bi^^enwited  the  last  wwd  has  the  value  of  0000  HEXADECIMAL 
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5  4.4.2.2.1  Notice  3  {B4C.1.5.2)  The  algorithm  is  unchanged.  However,  its  use  is  now 
mandated  on  all  three  standard  messages.  When  implemented,  under  the  option  rule,  it  is  still 
positioned  as  the  last  word,  but  when  rK>t  implemented  this  last  word  is  a  data  entity. 

5.4.4. 2.3  Execution  Time  (B5Q.1.5.3|  Indication  to  the  aircraft  of  the  execution  of  the  protocol 
checks  is  provided  by  the  setting  of  the  busy  bit.  The  maximum  time  for  which  busy  may  be  set 
is  1b00  microseconds  and  provision  is  made  for  the  store  to  report  its  actual  maximum  busy 
time.  Other  busy  bit  implementations,  including  time  maximums,  are  included  in  this 
paragraph. 

5.4.4. 2.3.1  Notice  3  fB4Q.l.5.3.|  Basically,  indication  is  no  longer  given  to  the  aircraft 
because  the  busy  bit  maximum  time  has  been  restricted  to  50  microseconds.  There  are  certain 
other  busy  bit  implementation  changes  also,  mainly  to  bring  K/iiL-STD'1760A  and 
MIL-STD-1553B  Notice  2  into  line  with  each  other. 

5.4.4.2.4  Mecsace  Acknowledomont  1850.1.5.41  Stores  acknowledge  receipt  of  a  message  if  (hv 
status  word  response  is  generated  with;  Message  Error  bit  set  to  logic  O,  Service  Request  bit  set 
to  logic  O.  Busy  bit  set  to  logic  O,  and  Service  Request  bit  set  to  logic  0  in  the  subsequent  status 
word,  providing  the  Busy  bit  is  also  set  to  logic  O. 

5.4. 4. 2.4.1  Notice  3  This  requirement  has  bee.n  eliminated. 

5.4.4  2.5  Service  Requirement  Notification  (B50.''.5  5]  Service  request  notification  uses  the 
service  request  bit  in  the  Status  word.  Multiple  requests,  that  is  more  than  one  request 
condition  active,  are  allowed  and  the  implementation  is  specified. 

5. 4. 4.2.6. 1  Notice  3  (B4Q.  1.5.4)  Obviously  the  service  request  bit  is  still  in  use,  bul  multiple 
requests  are  handled  in  a  totally  different  imoiementation. 

5.4. 4.2. 6  Request  Servicing  (E5Q. 1.5.6)  The  aircraft  extracts  the  servicing  required 
informa'  3n  by  demanding  the  Vector  Word.  It  rrust  do  this  on  a  high  priority  basis  and 
r.cknowledge  receipt.  The  vector  word  content  is  defined. 

5. 4.4.2. 6.1  Notice  3  fB4Q.1.5  5/6/7)  The  aircraft  still  extracts  the  servicing  required  data 
by  use  of  the  vector  word.  However,  the  priority  requirement  has  been  eliminated  as  has  the 
receipt  acknowledgment.  The  vector  word  content  has  been  completely  redefined  and  also 
included  are  the  rules  tor  retention  of  both  the  vector  word  and  any  associated  sub-address 
contents.  Both  the  LDD  and  Notice  3  use  a  figure  tc  show  the  general  form  of  a  service  rec’fest 
protocol  and  it  is  important  to  note  that  these  now  have  totally  different  protocols. 

5. 4.4. 2. 7  Request  Acknowledgment  IB5Q. 1.5.7)  4  protocol  for  vector  word  receipt  is  fully 
defined  including  the  responses  when  multiple  requests  are  being  serviced. 

5  4.4.2. 7.1  Notice  3  These  requirements  have  been  eliminated. 

5.4.4. 2. 8  Fault  Notification  fBSO. 1.5.8)  This  paragraph  provides  the  rules  fer  use  of  the 
service  request  bit  in  the  status  word. 

5.4.4.2.3.1  Notice  3  This  paragraph  has  been  eliminated  by  folding  the  requirements  into 
B40. 1.2.3. 
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5.4.4.2.9  Data  Consistency  [B5Q.  1.5.9)  The  data  consistency  requirements  are  spelled  out  here 
and  this  includes  a  protocol  for  the  recipient  of  the  consistency  state. 

5.4.4.2.9.1  Notice  3  This  requirement  has  been  eliminated. 

5.4.4.3  Linked  Transfers  fBSQ.i.S.lQ)  The  linked  transfer  requirements  are  undefined,  but 
sub-address  14  is  reserved  for  this  purpose. 

5.4.4.3  1  Notice  3  (B40. 1.5.81  This  requirement  is  now  called  Mass  Data  Transfer  and  the 
sub-address  14  reservation  is  now  in  use  for  its  intended  purpose.  A  full  protocol  is  specified 
for  bi-directional  data  transfer  called  out  as  Download  Mode  (aircraft  to  store)  and  Upload  Mode 
(Store  to  Aircraft).  Allowance  has  been  made  for  transfer  of  up  to  255  files  each  containing  up 
to  255  records  where  a  record  is  up  to  255  blocks  of  29  words,  that  is  29  X  255  X  255  X  255 
or  1 .885,725  data  words  per  file.  Three  basic  types  of  messages  are  used: 

a  Transfer  Control  (TC)  -  The  aircraft  uses  this  message  to  control  the  mass  data 
transfer  protocol. 

b.  Transfer  Monitor  (TM)  •  The  store  uses  this  message  to  advise  the  aircraft  of 
transfer  status. 

c.  Transfer  Data  (TD)  -  This  is  used  by  either  aircraft  or  store  for  the  actual  data 
transfer. 


5.4.4.4  Carriage  Store  Routing  fB5Q.1.5.111  The  procedure  is  undefined.  However,  sub¬ 
addresses  03  and  05  are  reserved  for  this  purpose  and  the  MIL-STD-1760A  message  length  is 
established  as  30  (thirty)  words  to  allow  introduction  of  this  facility  at  a  later  date. 

5.4.4.4.1  Notice  3  (640.1.5.9)  The  procedure  is  Still  undefined  and  the  reservation  of  sub¬ 
addresses  03  and  05  has  been  canceled.  All  messages  are  still  restricted  to  30  (thirty)  data 
words,  although  Carriage  Store  Routing  is  no  longer  specified  as  the  reason. 

5.4.4.5  Message  Requirements  (B5Q.2]  The  requi.ements  for  both  standard  and  non-standard 
data  messages  are  fully  defined,  with  the  former  restricted  to  those  for  Critical  Control,  Critical 
Monitor  and  Store  Description. 


5.4.4.5.1  Base  Message  Formats  fB5Q.2.1|  The  message  is  defined  as  a  30-word  message 
consisting  of: 


a.  Word  01  - 

b.  Word  02  - 

c.  Word  03  - 

d.  Wcrd  04  - 
thru 
Word  29 

e.  Word  30  - 


Header  (some  header  words  already  definedl/reserved) 
Validity  words  (1  bit  per  word  with  bits  15  and  16 

of  word  03  always  set  to  logic  0) 
Data  words  (up  to  26  data  words  are  available  for  use) 


Checksum  or  0000  HEXADECIMAL  (LAST  WORD  H  26 
data  words  are  in  use) 


5.4  4.5.1. 1  Notice  3  fB4Q.2.i)  The  message  is  Still  defined  as  a  30-word  message,  However, 
the  make  up  of  the  message  is  slightly  different  in  two  ways.  First,  the  data  word  field  is  now 
02-29  with  the  validity  words  optional,  both  in  use  and  position,  for  all  except  critical 
messages.  Secondly,  the  checksum  use  is  optional  for  all  non-standard  messages  and  there  is  no 
longer  a  requirement  to  use  the  alternative  of  0000  HEXADECIMAL. 


5.4.4.5.2  Mission  Stora  Control  (B5Q.2.2.1)  This  is  a  30-word  message,  utilized  as  follows: 
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a  Header  (0400  HEX) 

b.  Validity 

c.  Control  Words  (14) 
d  Reserved  Words  (12) 

e.  Checksum 

The  14  control  words  can  be  further  broken  down: 

a  Critical  Control  1  and  2 

b.  Critical  Authority  1  and  2 

c.  Aircraft  System  Time  (2) 
d  Fuzing  Mo^  Selection 

e.  Arming  Time/Oistance  for  various  modes  (4) 

f.  Selection  of  Rata  or  Number  to  Fire 

g.  Discrete  Control  1  and  2 

5  4.4.5.2.1  Notice  3  fB40.2.21|  Prime  differences  are  the  reduction  in  control  words  from  14 
to  1 1  and  the  consequent  increase  in  reserved  words  from  12  to  15.  The  control  word  changes 
are  that  the  Aircraft  System  Time  and  Discrete  Controi  has  been  eliminated  and  selection  of  rate 
or  number  to  fire  has  become  2  (two)  words,  entitled  Fire  Interval  and  Number  to  Fire. 

5.4.4.5.3  Mission  Store  Monitor  fB5Q.2.2.g|  This  is  a  30'Word  message,  utilized  as  follows: 

a  Header  (0420  HEX) 

b.  Validity 

c.  Monitor  Words  (3) 
d  Reserved  Words  (3) 
e.  Checksum 

The  3  monitor  words  can  be  further  broken  down: 

a  Store  Identity  Code 

b.  Status  of  Critical  Control  1  and  2 

5.4.4.5.3.1  Notice  3  IB40.2.2.21  Prime  differences  are  the  increase  in  monitor  Words  from  3 
to  4  and  the  consequent  reduction  in  reserved  words  from  23  to  22.  The  monitor  word  changes 
are;  Ihe  Store  Identity  Code  eliniinated,  Fuzing/Arming  Mode  Status  added,  and  Protocol  Status 
added.  The  Status  of  Critical  Control  1  and  2  words  have  been  re-named  Critical  Monitor  1  and 
2 . 

5.4 .4.5.4  SlQffl.  Description  Message  fB5Q.2.2.3]  This  message  basically  provides  two 
facilities:  Store  Identification,  either  binary  or  alpha-numeric,  and  Store  Data  Transfer 
requirements.  The  store  identification  facility  Is  discussed  first.  A  30-word  Store  Description 
A  message  is  utilized  as  follows: 

a  Header  (0421  HEX) 

b.  Store  Description  Page  Number  (0  DECIMAL) 

c.  Country  Code 

d  Store  Identity  Code  (BINARY) 

e.  Store  Type  ASCII  (5) 

f.  Implementation  of  Receive  Sub-addresses  0-31  (2) 

g.  Implementation  of  Transmit  Sub-addresses  0-31  (2) 
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h.  Maximum  Receive  Busy  Time 

i .  Maximum  Synchronize  Mode  Command  Busy  Time 
) .  Maximum  Power-up  Busy  Time 

k.  Maximum  IBIT  Busy  Time 

l.  Reserved  Words  (12) 

m.  Checksum 

The  store  description  page  number  word  (0)  and  the  four  sub-address  implementations  are 
connected  with  the  Store  Description  B  utilization.  The  five  store  type  ASCII  words  give  in  fact 
ten  alpha-numeric  characters  because  each  16  bit  word  is  split  into  2X8  segments. 

Store  Description  message  B  is  also  a  SO-word  message  and  utilized  as  follows: 

a  Header  (0422  HEX) 

b.  Store  Description  Page  Number  (1-62  DECIMAL) 

c.  Header  Code  allocated  to  described  message 

d.  Data  Entity  Codes  for  data  words  4  through  29  of  described  message  (26) 

e.  Checksum 

By  use  of  certain  bits  in  the  Synchronize  with  Data  Word  mode  code,  the  aircraft  can,  as  an 
option,  get  the  store  to  identify  itself  (message  A)  and  then  select  the  pages  (B  messages) 
detailing  the  core  receive  and  transmit  data  requirements.  These  pages  are  allied  to  the  specific 
sub-addresses  notified  in  message  A  by  page  number.  1-62.  Note  that  as  each  message  is 
described  it  carries  its  own  unique  header  word. 

5.4.4.5.4.1  Notice  3  (B4Q.2.2.31  Only  the  first  facility,  that  given  in  the  old  message  A.  now 
remains.  It.  the  Store  Description  Message,  is  still  a  30-word  message,  albeit  with  a  slightly 
altered  utilization: 

a  Header  (0421  HEX) 

b.  Country  Code 

c.  Store  Identity  -  BINARY 
d  Store  Identity  •  ASCII  (8) 

e.  Maximum  IBIT  Time 

f.  Reserved  Words  (17) 

g.  Checksum 

Obviously,  with  the  abandonment  of  the  Store  Data  Transfer  Requirement  protocol,  the  sub¬ 
address  implementation  and  Store  Description  Page  Number  words  have  been  eliminated.  As 
discussed  earlier,  the  use  of  busy  has  almost  been  totally  negated  and  this  has  therefore  led  to  the 
removal  of  all  the  busy  time  words.  Last,  but  by  no  means  least,  further  research  showed  that 
10  alpha-numeric  characters  was  insufficient  for  certain  'pod'  stores,  for  example 
AN/ALO-137A(V)10.  and  consequently  8  (eight)  words  have  been  allocated  for  this  function. 
These  8  words  are,  once  again,  split  into  2X8  segments  giving  the  requisite  16  alpha-numeric 
characters. 

5.4.4.5.5  Nuclear  Weapon  Control  Message  (B5Q.2.2.4)  This  is  not  a  standard  message  required 
by  MIL-STD-1760A,  but  may  of  course  have  such  a  requirement  specified  In  the  System  2 
Specification.  However,  MIL-STD-1760A  does  specify  that  receive  sub-address  07  is  reserved 
for  these  messages. 

5.4.4.5.5.1  Notica  3  (B40.2.2.4)  The  reserve  requirement  has  been  changed  from  one  to  two 
sub-addresses  namely  19  and  27. 
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5.4.4.5.6  Nuclear  Weapon  Monitor  Message  (B5Q.2.2.51  This  is  not  a  standard  message 
required  by  MIL-STD-t760,  but  may  of  course  have  such  a  requirement  specified  in  the  System 
2  Specification.  However,  MIL-STD-1760A  does  specify  that  transmit  sub-address  07  is 
resen/ed  for  these  messages. 

5.4.4.5.6.1  Notice  3  {B4Q.2.2.5|  The  reserve  requirement  has  been  changed  from  one  to  two 
sub-addresses  namely  19  and  27. 

5.4  4.5.7  Non  Standard  Messages  fB5Q.2.1]  All  messages  not  discussed  earlier  fall  into  this 
category.  These  messs^es  are  of  any  length,  as  determined  by  the  store,  from  5  (five)  to  30 
(thirty)  words.  Utilization  is  as  follows: 

a  Header 

b.  Validity  (2) 

c.  Data  Entities,  as  chosen  by  the  store  and  registered  in  the  ICD  ( I  -26) 

d.  Checksum 


5.4.4.5.7.1  Notice  3  (B40.2.1]  There  are  two  prime  differences  introduced  by  Notice  3, 
namely:  Validity  is  optional  and  Checksum  is  optional.  This,  therefore,  gives  a  possible  message 
length  of  2  (two)  to  30  (thirty)  words  incorporating  1-29  Data  Entities. 

5.4 .4.6  Standard  Data  Entities  fB50.3)  These,  utilized  as  described  earlier,  are  split  into  four 
categories: 

Control/Monitor  and  Protocols  (43)  Aircraft  Data  (74) 

Target  Data  (52)  Trajectory  Data  (54) 

With  the  data  entities  are  seven  diagrams  defining: 

Aircraft  Axis  System  Store  Axis  System 

Earth  Axis  System  Aircraft-Store  Alignment 

Earth-Aircraft  Alignment  Target  Position  XYZ 

Target  Position  ■  Store  Trajectory  (polar) 


5.4 .4.6.1  Notice  3  (B40.3)  Major  differences  are  in  the  seven  diagrams  and  the  numbers  of 
data  entities  which,  overall,  increased  the  coverage.  Typically  these  are: 

Control/Monitor  and  Protocol  (24)  Aircraft  Data  (81) 

Target  Data  (67)  Trajectory  (42) 


With  the  data  entities  are  eight  diagrams  defining: 


Aircraft  Body  Axis 
Earth  Axis  (unchanged) 

Earth  •  Aircraft  Alignment  (some  notes 
very  different) 

Target  and  Waypoint  Position  XYZ  from 
current  position 


Store  Body  Axis 

Aircraft-Store  Alignment  (very 
different) 

Aircraft,  Target  and  Waypoint  Position 
XYZ  to  fixed  point 

Target  Position  -  Store  Trajectory 
[polar]  (minor  change) 
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6.  THE  MtL-STD-1760  APPLICATION  PROCESS 


This  section  covers  the  process  by  which  the  MiL'STD-1760  requirements  should  be  covered  by 
system  design. 

6.1  Definition  of  the  MIL-STD-176QA  ADolicalion  Process  The  MIL-STD-1760  Application 
Process  encompasses  all  those  activities  that  are  associated  with  the  implementation  of  the  AEIS 
in  an  aircraft  or  store  program.  These  activities  are  those  which  are  concerned  primarily  with 
the  solution  of  the  interoperability  requirements  of  the  aircraft  and  stores,  but  also  considers 
those  which  are  specific  to  the  design  of  particular  avionic  subsystems,  and  which  may 
incorporate  non-AIS  functions.  Clearly,  there  is  a  Tme  dividing  line  between  these  two  types  of 
activity  .  The  biggest  problem  In  defining  the  proper  domain  or  boundaries  of  MIL-STD-1760 
implementation  requirements  occurs  in  defining  how  ‘deep*  into  the  subsystem  which  supports 
the  interface,  (usually  the  stores  management  system),  that  requirements  must  be  defined.  At 
one  extreme,  the  implementation  of  MIL-STD-1760  consists  of  merely  supplying  the  connectors 
and  associated  wiring,  to  which  the  specified  functions  are  supplied.  The  other  extreme  involves 
the  design  of  all  the  subsystems  which  are  behind  the  interface.  These  may  include  all  the 
electronic  subsystems  in  the  case  of  stores  and,  in  the  case  of  the  aircraft,  such  subsystems  as 
the  SMS,  the  power  distribution  system,  the  analog  networks,  the  aircraft  data  acquisition 
systems,  and  an  element  of  aircraft  wiring.  This  document  addresses,  principally,  the 
implementation  of  MIL-STO-1760  cn  the  aircraft  side  of  the  intedace.  The  point  at  which  the 
dividing  line  between  MIL-STO-1760  implementation  and  subsystem  (or  equipment)  design 
should  oe  drawn  is  a  subjective  issue,  and  may  well,  in  practice,  depend  upon  the  constraints 
that  prevail  in  a  particular  implementation  (Section  7  describes  those  functions  that  are 
considered  to  be  contained  within  the  AIS).  Any  discussion  providing  practical  implementation 
guidance  must  clearly  cover  particular  system,  hardware  and  software  considerations  and  as 
such  the  discussion  must  encroach  on  the  avionic/store  subsystem  designs.  Consequently,  it  is 
important  firstly  to  define  the  boundary,  or  definition,  of  the  system  which  will  implement 
MIL-STO-1760.  that  is  the  AEIS  Implementation  System  (AIS).  Thus,  this  document  addresses 
the  application  proces.«es  and  implementation  issues  which  are  associated  with  the  AIS  as  it 
impacts  the  aircraft.  The  MIL-STD-1760  Application  Process  tends  to  follow  the  phases  of  any 
normal  acquisition  program.  These  phases  may  be  summarized  as: 

Phase  1  -  AIS  System  Definition  Phase  2  ■  AIS  System  Performance  Definition 

Phase  3  -  AIS  Design  and  Development  Phase  4  -  In-Service  and  Planned  Improvements 

Figure  6.1  shows  the  principal  issue '>  that  need  to  be  considered  during  each  of  these  phases.  The 
paragraphs  of  this  document  discuss  implementation  issues  and  guidance  associated  with  each  of 
these  phases.  The  following  table  €.1  oofines  the  content  of  each  paragraph. 

6.2  Discussions  of  issues  and  Guidelines  in  Sections  7  Through  13  As  indicated  in  table  6.1 , 
sections  7  througli  13  Include  the  issues  and  guidelines  relevant  to  each  stage  of  a 
MIL-STD-1760  implementation.  Each  of  these  paragraphs  Include  a  list  of  issues  which  relate 
to  the  paragraph  title.  The  issues  and  related  guidelines  have  been  derived  from  four  models, 
which  separately  studied  the  implementation  of  MIL-STD-1760.  These  are  defined  as: 

a  The  AEIS  Validation  System  Rig  (AVS  RIG).  This  is  a  full  hardware  and  software 
implementation  of  MIL-STD-1760. 

b.  The  F-16  Case  Study  (F-16C/D).  This  study  undertook  a  MIL-STD-1760 
Implementation  design  on  the  F-16C/0  aircraft. 
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1. 


AIS  System 
Definition  Phase 


AIrcraR  RaquIrcmenU 

FIghUr,  Bomber,  Ground  Attack,  ASW,  AEW  etc. 

Cost 

Timescales 

AIrcraR  Perrornunce  Requirements 

Physical 

Basic  Sensors 

Safety  and  Mission  Success 

Store  Types 

S.S.l. 

Mandatory  non  'SSI  for  which  no  alternative  SSI  exists 
MIL-STD-1760  (SSI)  class  definition 
Class  I,  lA,  II,  IIA 

Overall  Weapon  System  Functional  Partitioning 
MFCD 

Ballistic  Data  Store  Location 
Emergency  Jettison  Facility 
Safety  Critical  Operations  vis  •  a  •  vis 
Non  Safety  Critical  Operations 
etc 


2. 


Al^  System  Performance 
Definition  Phase 


•  Functional  Characteristics 

•  Performance  Characteristics 

•  Safety  and  Succeu  Characteristics 

•  Physical  Characteristics 

•  Environmental  Conditions 

•  Reliability  it  Maintainability  Characteristics 

•  System  Interfaces  (Includes  SSI  and  NSSI  Considerations) 


3.  AIS  Design  and 

Development  Phase 

1 

1 

•  Functional  Partitioning 

•  Internal  Interfaces 

•  ^stem  Design 

•  Equipment  Design  (Electrical) 

•  Equipment  Design  (Mechanical) 

•  SoRware  Design 

•  AIrcraR  Installation 

•  R  It  M  Analyses  (FSA) 

•  System  Verification  &  Validation 

•  QuallRcatlon  A  Certification 

AIS  In  •  Service  and 
Planned  Improvements  Phase 


•  Support  Facilities 

•  Application  of  Emerging  Technology 

•  New  Weapons 

•  Application  to  other  AIrcraR 


FIGURE  6.1  AIS  Implementation  Phases 
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TABLE  6.1  Relationship  between  Paragraphs  and  Application  Process  Phases 


Phase 

Section  Number 

Section  Title 

AIS  System  Definition  Phase 

7 

AIS  System  Definition  Issues  & 
Guidelines 

AIS  System  Performance 

Definition  Phase 

8 

AIS  System  Performance  Issues  & 
Guidelines  (this  includes  ASI  interface 
definition) 

AIS  Design  &  Development  Phase 

9 

AIS  System  Design  Issues  &  Guidelines 

1  0 

AIS  Eauioment  Issues  &  Guidelines 

1  1 

AIS  Software  Issues  &  Guidelines 

1  2 

AIS  Installation  Issues  &  Guidelines 

1  3 

AIS  System  Integration.  Testing  &  In- 
Service  SuDDort  Issues  &  Guidelines 

c.  The  survey  of  planned  MIL-STD-1760  implementation  on  aircraft  and  stores, 
d  General  Contractor's  Experience. 

Each  issue  has  been  derived  from  one.  or  more,  of  these  models.  The  source  of  the  guidance  has 
been  derived  from  one,  or  more,  of  the  foibwing  five  processes; 

a  HIGH  LEVEL  system  design  considerations 

b.  AIS  DESIGN  activities 

c.  MIL-STD-1760  Test  and  Evaluation  (1760  EVAL)  activities 
d  Evaluation  of  the  LDD  (LDD  EVAL) 

e.  Evaluation  of  the  overall  AIS  System  (AIS  EVAL) 

Table  6.2  shows  the  applicability  of  each  of  these  live  processes  to  the  four  implementation 
models.  The  lists  of  issues  contained  in  sections  7  through  13  each  contain  the  following 
information: 

a  The  paragraph  number 

b.  The  issue  title 

c.  The  definition  or  explanation  of  the  issue 

d  Implementation  guidance  for  the  issue  (This  guidance  may  have  been  derived  from 
more  than  one  example.  In  which  case,  the  lessons  learned  from  each  example  have  been 
consolidated  into  the  guidance  given.) 


Table  6.2  Applicability  of  guidance  source  to  implementation  example 


IMPLEMENTATION  MODEL 

GUIDANCE  SOURCE  1 

HIGH  LEVEL 

AIS  Design 

1760  Eval 

LDD  Eval 

AIS  Eval 

AVSRig 

X 

X 

X 

X 

X 

X 

X 

X 

Survey 

X 

Contractor  Experience 

X 

X 

1 

Note:  X  indicates  Issues  &  Guidelines  Derived 


6.3  CROSS  REFERENCE  Section  14  of  this  document  contains  an  index  cross  referencing  the 
issues,  and  MIL-STD-1760A. 
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7.  AIS  SYSTEM  DEFINITION  ISSUES  AND  GUIDELINES 


7.1  Overall  AIS  Definition  This  section  describes  those  issues  which  relate  to  the  definition  of 
the  AEIS  Implementation  System  (AIS)  from  an  overall  system  viewpoint.  The  section  contains 
the  following  major  paragraphs: 


Overall  definition  of  the  AIS  7.1 

Prime  objectives  and  requirements  that  drive  the  AIS  design  7.2 
Overall  weapon  system  functional  partitioning  7.3 

Weapon  system  partitioning  guidance  7.4 

Future  growth  potential  7.5 


7.1.1  AIS  PelinltlQn 

ISSUE;  Define  the  functional  boundary  of  the  AIS  and  how  these  functions  are  implemented  in  the 
AIS. 

GUIDANCE:  The  AIS  has  been  defined  as  the  system  that  implements  the  AEIS.  It  is  important  to 
recognize,  particularly  with  existing  aircraft,  that  this  is  not  an  exclusive  definition.  As  shown 
in  figure  7.1,  the  AIS  system  may  not  necessarily  be  a  single  specification  and  procurement 
process,  and  also  the  equipment  or  equipments  that  fulfill  the  AIS  function  may  additionally 
implement  other  functions.  Where  an  existing  aircraft,  or  aircraft  design,  is  upgraded  to  provide 
MIL-STD-1760  capability  then  existing  equipment  will  probably  be  retained  to  provide  part  of 
the  interface.  This  existing  equipment  will  then  become  part  of  the  AIS  which  will  therefore 
implement  functions  other  than  pure  MIL-STD-1760.  It  is  the  determination  of  which  functions 
should  also  be  implemented  in  the  AIS  that  is  the  most  important  factor  in  AIS  design.  Section  7 
addresses  principally  the  AIS  definition,  but  also  briefly  considers  non-aircraft  functions.  In 
determining  which  functions  are  included  in  the  AIS.  some  will  usually  be  judged  on  technical 
considerations  alone.  While  this  approach  has  been  followed  in  much  of  the  information  here,  it 
is  important  to  recognize  that  technical  elegance  alone  is  not  a  true  objective.  The  true 
objectives  are  those  measurable  for  the  aircraft  program,  and  are  essentially  cost,  timescale  and 
aircraft  performance. 


Boundary  ot  AIS 
Implamantotlon 


Boundary  ot 
Pura  AIS 
Functions 


Spoelttc  procurod  aqulpmanta  may 
Indudo  both  'pura  AIS'  and 
non  -  AIS  function  a 


FIGURE  7.1  Non-exdusivity  of  the  AIS 
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7.1.2  IfnDlemflntaiiQn/PrQcurement  Strategy 

ISSUE:  Should  MIL-STD-1760  be  implemented  fully  or  at  all  on  an  aircraft  or  store  program? 

BACKGROUND:  For  most  major  system  development  efforts,  the  Government  is  careful  not  to 
force  specific  designs  on  competing  contractors.  For  this  reason.  MIL-STD-1760 
implementation  direction  has  historically  been  soft,  such  as;  'the  Contractor  should  consider  use 
of  MIL-STD-1760."  Further,  as  the  standard  interface  is  a  solution  for  life-cycle  electrical 
integration  problems  and  may  be  seen  as  an  expensive  alternative  for  integrating  a  single  store 
type,  pressure  will  be  placed  on  project  offices  to  grant  exceptions  to  a  MIL-STD-1760 
interface  requirements.  Industry  cannot  solve  this  problem  if  they  have  to  provide  lowest  cost 
solutions  to  immediate  electrical  integration  problems. 

GUIDANCE:  The  government  has  to  recognize  the  longer  term  benefits  of  MIL-STD-1760  and 
accept  the  initial  investment  required  for  its  implementation.  Criteria  for  selecting 
implementation  targets  could  be: 

a  All  new  store  developments  (or  major  modifications) 

b.  All  future  aircraft 

c.  Existing  aircraft  integrating  new  stores 

Industry  and  the  government  could  also  ensure  that  even  when  MIL-STD-1760  is  not  directed, 
the  design  is  not  one  that  inhibits  downstream  implementation  of  the  standard. 

7.1.3  Partial  MIL  STD-176Q  Implementation 

ISSUE:  Whal  is  the  useability  of  partially  compliant  MIL-STD-1760  interfaces? 

BACKGROUND:  MIL-STD-1760  contains  many  specific  and  detailed  requirements.  With  an 
aircraft  such  as  the  F-16  there  are  existing  equipments  that  provide  many  of  the  MIL-STD- 
1 760  features  although  not  necessarily  with  full  compliance  to  the  requirements.  An  example  of 
this  is  current  limiting.  Some  of  the  MIL-STD-1760  requirements  such  as  1.6  GHz  only  apply 
to  store  types  not  planned  for  all  locations  on  the  aircraft.  Arguments  could  be  formed  that  these 
requirements  need  not  then  be  implemented. 

GUIDANCE:  The  use  of  partially  compliant  MIL-STD-1760  interfaces  is  not  permitted.  MIL- 
STD-1760  implementation  on  aircraft  is  intended  to  remove  the  requirement  for  further 
electrical  modification  during  the  airframe  life,  implementation  of  non-compliant  sub  sets  will 
lead  to  uncertainty  as  to  the  aircraft  compatibility  of  future  stores.  To  avoid  unnacessary  costs 
MIL-STD-1760  provides  for  four  classes  of  interface  (I,  lA,  II,  IIA)  and  implementations  must 
conform  to  the  relevant  requirements. 

RATIONALE:  All  MIL-STDs  are  subject  to  review  and  any  requirements  found  to  be  unreasonable 
should  be  removed  from  future  issues  (or  notices). 

7.1.4  Impact  of  Integrated  Avionics 

ISSUE:  How  is  the  boundary  of  the  AIS  defined  in  an  integrated  avionics  architecture? 

BACKGROUND:  The  trend  towards  integrated  avionics  is  typified  by  programs  such  as  Pave 
Pillar.  Although  these  programs  have  as  their  prime  objectives  reduced  lifetime  cost  and 
increased  performance  the  program  together  with  various  supporting  technology  programs  have 
produced  several  design  imji^ementations.  These  include: 
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a  A  common  system  architecture 

b.  Specifications  for  backplane  and  high  speed  bus  connections 
&  Common  modules  such  as  processors,  interfaces 
d  Flight  tine  removability  of  modules 
a  Integration  of  multiple  systems  into  3/4  AIR  form  racks. 

f.  Mult^le  processing  tasks  on  single  modules  and  redistribution  of  processing  tasks  for 
fault  tolerance 


These  concepts  are  shown  in  figure  7.2. 

GUIDANCE:  The  potential  problems  in  definirtg  the  AIS  boundary  arise  from  points  e  and  f.  above. 
The  following  guidance  should  clarify  the  position: 

a  The  lack  of  an  LRU  physical  boundary  in  an  integrated  rack  does  not  mean  that  there  is 
no  AIS  boundary.  If  various  modules  inside  that  rack  can  be  determined  as  AIS  modules  then  their 
boundary  forms  the  AIS  boundary. 
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b.  The  use  of  shared  data  buses  and  shared  processing  between  the  AIS  and  other 
functions  (excluding  the  SMS)  is  discouraged  because  of  the  high  safety  requirements  and  the 
difficulties  in  proving  integrity  in  such  a  shared  system.  See  also  paragra^  9. 

c.  If  a  data  bus  is  shared  between  the  core  AIS  and  another  system  then  that  data  bus 
becomes  in  effect  part  of  the  AIS.  The  AIS  then  also  implements  Data  Bus  control  for  the  other 
system.  This  however  does  not  mean  that  the  AIS  becomes  the  whole  avionics.  The  core  AIS  is 
restricted  to  those  electrical  interfaces  and  data  directly  connected  with  the  MIL-STD-1760 
interface. 

d.  If  a  module  is  shared  between  the  core  AIS  and  another  system  then  that  module  data 
bus  becomes  in  effect  part  of  the  AIS.  The  AIS  then  also  implements  features  of  the  other  system. 
This  again  does  not  mean  that  the  AIS  becomes  the  whole  avionics.  The  core  AIS  is  again 
restricted  to  those  electrical  interfaces  and  data  directly  connected  with  the  MIL-STD'1760 
interface. 

e.  Where  the  allocation  of  modules  and/or  data  buses  to  different  functions  is 
dynamically  reconfigured  for  fault  tolerance  then  the  boundary  of  the  AIS  will  be  dynamically 
reconfigure  at  the  same  time. 

7.2  Program  Objectives  As  described  above,  the  prime  effectives  are  cost,  timescale  and 
aircraft  performance.  These  are  discussed  here  in  aircraft  terms.  It  is  important  that  these 
objectives  are  clearly  set  for  the  airaaft  program,  and  set  in  outline  for  the  AIS  program  before 
the  AIS  definition  commences.  Only  then  can  correct  decisions  be  made  relating  to  the 
implementation  of  the  AIS. 

7.2.1  Cost  Factors 

ISSUE:  What  are  the  AIS  Cost  Elements  and  what  is  their  magnitude? 

GUIDANCE:  AIS  Cost  has  three  elements:  cost  of  ownership,  cost  of  production,  and  cost  of 
development.  The  split  between  these  depends  on  the  number  of  aircraft  involved  in  the  program. 
Clearly  if  only  one  aircraft  was  produced  (as  in  a  demonstration  program)  then  the  development 
costs  might  exceed  all  the  other  costs.  It  is  the  general  case,  however,  that  the  Cost  of  Ownership 
exceeds  the  Cost  of  Production  which  exceeds  the  Cost  of  Development.  In  determining  the  cost 
constraints  of  the  AIS,  therefore,  priority  should  be  given  in  thal  order  to  the  costs. 

7.2.1. 1  Cost  of  Ownership  it  is  difficult  to  set  cost  constraints  in  monetary  terms  for  this 
element.  This  is  because  of  the  uncertainty  of  the  length  and  mode  of  service  the  AIS  will 
experience.  It  is  preferable  therefore  to  set  limits  on  the  factors  that  effect  Cost  of  Ownership, 
and  these  are  the  maintenance,  test  and  operation  costs  reflected  in  elements  as  shown  in  table 
7.1.  Specific  limits  for  these  factors  will  depend  on  the  specific  aircraft  and  service 
requirements. 

7. 2. 1.2  Cost  of  Production  It  is  easier  to  place  a  cost  limit  in  nnonetary  terms  on  production 
cost.  It  is  common  for  an  overall  target  cost  for  repeat  aircraft  (build  or  retrofit)  to  be  set  at  an 
early  date,  and  it  is  not  difficult  to  assess  the  AIS  portion  of  this.  From  previous  experience,  it 
can  be  stated  that  for  a  new  aircraft  the  AIS  cost  might  be  between  1  -2%  of  the  repeat  cost  of  the 
aircraft. 
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TABLE  7.1  Table  Of  Cost  of  Ownership  Factors 


Factor 

Sub-elements 

Maintenance 

Reliability  (Mean  Time  Between  Defects  -  MTBD) 

Mean  Time  to  Repair  (MTTR) 

Scheduled  Maintenance  per  Riaht  Hour  1 

Test 

SiS)Oort  Equipment  Required 

Mean  Time-to-Test  (MTTT) 

BIT  Modes  and  Level 

Operation 

Averaoe  crew  time  for  AIS  per  mission 

7.2.1. 3  Cost  of  Development  It  is  only  possible  to  set  limits  on  the  cost  of  project  specific 
development.  Non  specific  research  and  development,  whether  contractor  or  government 
funded,  can  only  be  assessed  and  limited  by  consideration  of  more  global  factors.  The  limit  to  be 
set  on  the  AIS  development  cost  will  depend  on  the  specific  nature  of  the  project,  but  for  a  new 
aircraft  program  a  cost  of  1%  of  the  total  development  cost  would  not  be  unexpected. 

7.2.2  Timescale  Factors 

7.2.2.1  Development  Timescales 

ISSUE:  What  are  the  timescale  considerations? 

GUIDANCE;  Timescale  is  an  important  factor  to  be  defined  before  design  consideration  of  the  AIS 
is  undertaken.  On  a  typical  aircraft  development  project,  times  of  3  years  to  first  full  system 
flight,  and  5  years  to  in-service  date  might  be  exp^^.  For  many  programs  a  limited  capability 
AIS/SMS  (jettison  only)  may  be  required  at  an  early  date  to  allow  developmental  flying.  It  is 
important  that  the  project-specific  timescales  are  recognized  at  an  early  date. 

7  2.2.2  Aircraft  and  Store  Timescale  Compatibility 

ISSUE:  Will  aircraft  be  MIL-STD-1760  compatible  in  time  for  MIL-STD-1760A  weapons? 

BACKGROUND:  This  issue  concerns  the  problem  of  various  aircraft  and  weapon  programs 
implementing  MIL-STO-1760  in  different  arrd  potentially  conflicting  timeframes.  An  example 
is  a  complex  air-to-ground  weapon  requiring  full  MIL-STD-1760  capability  with  an  IOC  of 
1995,  when  the  associated  aircraft  will  not  have  a  full  implementation  until  2000. 

GUIDANCE:  A  resolution  of  this  issue  could  be  the  establishment  of  a  MIL-STD-1760  Control 
Board  reporting  to  management  levels  within  DoO.  This  is  the  same  as  that  for  other  management 
issues.  A  Control  Board  could  be  implemented  that  can  dictate  oompatibie  mplementation 
direction  among  different  programs,  support  implementation  funding,  and  rTK>nitor 
implementation  dedslons.  This  board  would  establish  policies  that  will  ensure  oompatibie 
implementations. 
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ISSUE:  Define  overall  aircraft  requirements  which  impact  the  design  of  the  AIS  (such  as  Mission 
Success,  System  Safety.  Physical  Constraints). 


Aircraft  Program  Without  a  clear  understanding  of  the  aircraft  mission  and  performance 
requirements,  definition  and  subsequent  design  of  the  AIS  will  be  poor.  Aircr^  performance  has 
many  elements,  but  the  most  relevant  are  listed  below.  Only  when  these  factors  have  been  fuHy 
defined  can  the  AIS  contribution  be  defined.  Section  8  provides  specific  AIS  performance 
requirements. 


Missions 

Strategic 

Tactical 

Defense 

Stores 

Number  of  Ijocations 

Different  Types 

Rates  of  Ernployment 

Targeting 

Information  Sources 
Accuracy  of  Delivery 

Safety 

Ha2ards  per  Hour 

Mission  Aborts  per  Hour 

Weight 

Flight  Envelope 

Temperature 

Altitude 

BJC 

7.3  rh/nraii  Weapt^n  System  Functional  PartitioninQ 

ISSUE:  Which  weapon  system  functions  should  the  AIS  Implement? 

GUIDANCE:  Once  the  high  level  objectives  have  been  set.  as  descriaed  in  paragraph  7.2,  the 
aircraft  impiemenlor  can  commence  definition  of  the  AIS.  The  first  phase  of  this  is  to  determine 
the  key  functions  the  AIS  will  execute.  The  key  decision  in  this  determination  win  be  whether  to 
implement  a  separate  AIS  or  one  combined  with  the  Stores  Management  System  function. 

7.3.1  The  AIS  and  the  Stores  Management  System  fSMSi  function 

ISSUE:  Sho<nd  the  AIS  be  implemented  in  the  Stores  Management  System? 

BACKGROUND:  Although  there  is  no  common  definition  of  an  SMS  for  aircraft  (different 
functions  are  implemenied  in  different  aircraft  SMS)  there  is  a  a>mmon  core  of  SMS  functions 
nearly  always  implemented.  These  are: 

a  Weapon  Inventory 

b.  Store  Selection 

c.  Arm^  Control 
d  Release  Control 
e.  Jettison  Control 


It  common  tor  ttte  SMS  to  in^>lemont  control  of  power  and  dMa  toterfrcM  tor  eidsting  (non 
MIL-STD-1760)  Interface  stores. 
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GUIDANCE:  Given  the  above  SMS  definition,  the  AIS  should  definitely  be  incoiporated  with  the 
SMS  function  for  new  aircraft  types  and  if  equ^ment  capability  or  expa:.sion  capability  exists, 
tlien  also  for  retrofit  or  upg'ade  aircraft  programs. 

~.3.2  Summary  of  Functional  Partitioning 

ISSUE;  What  are  the  main  allocalions  of  Weapon  System  functions? 

GUIDANCE:  Figure  7.3  shows  how  ail  of  the  furictions  of  the  total  weapon  system  {aircraft,  crew, 
stores)  have  to  be  split  between  the  AIS  the  stores  and  the  rest  of  the  aircraft  (including  crew). 
Table  7.2  lists  the  most  relevant  notentiat  functions  i'or  consideration  of  inclusion  in  the  AIS. 
Paragraph  7.4  provides  guidance  as  to  where  these  furctions  should  be  allocated.  Table  7.2  has 
been  marked  with  'X‘  to  siiow  where  functions  are  def  nitely  located,  ‘o'  where  they  are  probably 
located,  and  also  a  *  where  the  function  would  not  be  located  in  the  AIS  if  a  separate  SMS  were 
implerrented. 


FIGURE  '.3  Weapon  system  function  partitioning 


TABLE  7.2  Weapon  system  functions 


KEY  FUNCTION 

SUB  FUNCTIONS 

UXATICN  1 

AIS 

STORE 

AIRCRAFT 

STORE  INTERFACE 

MIL-STD-1760  -  AS! 

X 

MIL-SID  1760  -  MSI 

X 

Non-AEIS  Signals 

0 

HHI 

Post  Launch 

UJI 

0 

STORE  STATE 

State  Change  Prompt 

0 

State  Command 

■EH 

State  Monitor 

wm 

Power  Supply  Management 

n 

X  •  definite  location  o 

f  function  o  •  probable  location  of  function 

*  -  location  of  function  if  a  separate  SMS  implemented 
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TABLE  7.2  Weapon  system  functions  -  continued 


KEYFUn'CTION 


DATA  TO  STORE 


SUB  FUNCTIONS 


LOCATION 


STORE 


AIRCRAFT 


DATA  FROM  STORE 


STORE  SELECTION 


STORE  ARMING 


SrORE  RELEASE 


Store  to  Store  Data  Source 


Aircraft  Raw  Data  Source 


Unioue  to  Store  Formattin 


ReoomDutation  to  Store  Axes 


Interface  with  Store 


Raw  Data  Source 


Unique  to  User  Formattin 


Recomoutation  to  User  Axes 


Interface  With  Avionics 


Type  Determination 


Station  Determination 


Number  Selection 


Store  Initialization  Management 


Release  Pacffaae  Retention 


Armino  Mode  Determination 


Armina  Iniolementation 


Arming  Management 


Armino  Times  Computation 


Release  Prompt 


Suspension  Eguipirent  Management 


n  Bav  Management 


Release  Management 


Release  Timin 


Impact  Point  Determination 


Release  Seguence  Determination 


Hang-Up  Detection 


Balance  Management 


Engine  Control  Assistance 


Jettison  Prompt 


Selective  Jettison  Management 


Emergency  Jettison  Management 


Store  Safe  Verification 


Inventory  Determination 


Inventory  Confirmation 


Inventory  Update  in  Mission 


Displays 


Critical  Controls 


Non-Critical  Controls 


Suspension  Equipment  (S&RE 


S&RE  Management 


PAL  Code  Provision 


Two  Person  Action 


Crow  Controls 


Crew  Displays 


X  -  definite  location  of  function  o  -  probable  location  of  function 

*  «  location  of  function  if  a  separate  SMS  implemented 


STORE  JETTISON 


IN'vENTORY 


CRBV  INTERFACE 


NUCLEAR  CONTROL 
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7.4  Weapon  SvstBm  Partltlonlna  Guidance 

7.4.1  Store  interface 

ISSUE;  Definition  of  those  store  interface  functions  implemented  by  the  AIS. 

GUIDANCE: 

7-4. 1.1  MIL-STD-1 76Q-ASi  As  shown  in  figure  5.1.  the  ASI  is  the  final  point  of  the  aircraft 
implementation  of  MIL-STD-1 760.  It  is  therefore  not  implemented  by  the  store  and,  since  it  is 
a  pure  MIL-STD-1 760  function,  it  is  definitely  an  AIS  function. 

T.4.1.2  MIL-STD-1 760-MSI  As  shown  in  figure  5.1,  the  MSI  is  a  pure  store  function. 

T.4.1.3  Non-AEIS  Signals  These  are  the  signal  interfacos  to  stores  such  as  a  Sidewinder  and 
HARM  which  do  not  conform  to  MIL-STD-1 760A.  Many  signals  for  such  stores  are  almost 
identical  in  specification  to  MIL-STD-1 760A  signals  (Examples  are  power  and  video  signals). 
Even  signals  such  as  Sidewir>der  guidance  analogs,  that  are  electrically  incompatible,  contain  data 
types  common  with  MIL  STD-1 760  stores.  These  data  types  would  therefore  be  best  computed 
and  processed  by  the  AIS.  Application  guidance  for  new  aircraft  is  therefore  to  implement  non- 
AEIS  store  signals  In  the  AIS.  This  may  not  apply  to  retrofit  of  MIL-STD-1 760  lo  existing 
aircraft  designs.  In  such  cases,  it  is  possible  that  existing  equipment  and  wiring  are  present  that 
adequately  implement  tlie  required  interfaces.  Where  this  is  found,  then  non-AEIS  signals 
incompatible  with  MIL-STD-1 760  should  not  be  implemented  in  the  AIS,  except  where  there  is 
insufficient  space  for  retention  of  the  existing  equipment. 

Suspension  store  suspension  is  a  mechanical  function  and  has  little  in  common  with 
MIL-STO-1760  implementation.  It  is  therefore  considered  a  non-AIS  function,  but  the 
management  of  the  store  suspension  racks  and  launchers  may  be  implemented  by  the  AIS.  This  is 
discussed  in  7.4.7.  below. 

T.4.1.5  Post  Launch  Post-launch  aircraft-store  interfaces  can  be  by  radio  frequency  (RF) 
links,  laser  Illumination  or  direct  wire/fiber  connection.  These  mechanisms  have  little  in 
common  with  MIL  STO-1760  interfaces  and  are  not  best  implemented  in  the  AIS. 

7.4.2  Store  State 

ISSUE:  Definition  of  Store  State  functions  implemented  by  the  AIS. 

GUIDANCE: 

T.4.2.1  Slate  Change  Prompt  The  normal  ‘prompts’  for  initiating  changes  in  store  critical 
states  are  positive  crew  action  (Master  Arm,  Trigger,  etc)  or  automatic  analysis  of  threat  data. 
State  change  prompt  is  therefore  a  non-AIS  function  in  general  terms.  The  AIS  may  be  required 
to  implement  store-specific  change  prompts  when  a  change  is  detected  in  another  store. 

Examples  of  this  are  selecting,  arming  or  releasing  a  store  automatically  following  failure  or 
release  of  another  store.  Although  most  functionality  is  concerned  with  the  store  critical  state 
the  AIS  will  have  to  manage  the  store  mode  (for  example  slaving,  locked  etc). 

^  Staifl  .Command  MIL-STD-1760  specifies  in  detail  the  command  and  data  actions 
required  for  store  critical  state  changes.  The  generation  of  State  Commands  is  therefore  an  AIS 
function. 
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7.4.2  3  Stale  Monitor  MIL-STO-1760  specifies  in  detail  the  critical  monitor  mechanisms  and 
data  formats.  The  monitor  of  store  critical  state  and  comparison  against  commanded  states  is 
therefore  an  AIS  function. 

7.4. 2.4  Power  Supply  Different  store  states  may  require  different  power  supply  provisions. 
Since  the  power  Interfaces  are  defined  by  MIL-STD-1760  and  the  critical  state  is  demanded  by 
the  AIS,  then  the  management  of  power  is  an  AIS  function.  Note  however  that  data  specifying  total 
available  power  is  an  input  to  this  function  and  that  that  data  is  from  a  non-AIS  source. 

7.4.3  Data  to  Store 

ISSUE:  Definition  of  the  Data  to  Store  transfers  that  are  processed  by  the  AIS. 

GUIDANCE: 

7.4.3.1  Store  to  Store  Data  Source  Since  the  data  originates  In  the  store  this  is  not  an  AIS 
function.  Provision  of  network  paths  is  considered  to  be  an  AIS  function,  but  is  deHned  here 
under  (7.4.3.5)  Interface  to  Store. 

7.4 .3.2  Aircraft  Raw  .Data  Source  Clearly  this  is  not  an  AIS  function,  but  only  when  referred  to 
raw  data  such  as  radar  returns,  air  pressure  etc.  The  more  the  data  is  processed  then  the  more 
likely  the  function  should  be  in  the  AIS.  As  guidance,  if  the  data  resulting  from  a  process  or 
computation  is  only  used  by  stores,  then  the  AIS  or  even  the  store  should  implement  that 
process/computation. 

7.4 .3.3  Unique  to  Store  Formatting  MIL-STD-1760  defines  data  formats  for  stores,  but  these 
are  not  required  to  be  used  by  other  aircraft  systems.  Any  reformatting  required  solely  for 
stores  should  be  implemented  in  the  AIS. 

7.4.3.4  Recomoutation  to  Store  Axes  Target  and  aircraft  position  data  wilt  frequently  be 
referenced  in  the  aircraft  axis  system.  Store  suspension  will,  in  many  cases,  result  In  stores 
being  suspended  with  significant  angular  or  positional  offsets  from  the  aircraft  system  and, 
accordingly,  recomputation  to  the  store  axes  will  be  required.  MIL'STD-1760  provides  data 
formats  for  this  to  occur  either  in  the  store  or  the  aircraft.  The  location  of  this  function  will 
therefore  depend  on  the  store  Interface  Control  Document  (ICD).  Should  this  specify  the  store 
axes  as  the  reference  for  interface  data  then  the  AIS  will  have  to  recompute  lo  the  store  axes. 
Total  system  performance  will  be  higher  it  the  store  executes  the  recomputation.  The  AIS  will 
also  be  required  to  recompute  data  where  aircraft  da:a  is  not  provided  in  a  MIL-STD-1760 
compatible  axis  system. 

7.4.3.5  Interface  to  Store  As  discussed  in  7.4.1,  this  is  an  AIS  function. 

7.4.4  Data  from  Store 

ISSUE:  Definition  of  the  Data  from  Store  transfers  processed  by  the  AIS. 

BACKGROUND:  Data  from  stores  is  a  similar  issue  to  data  to  stores,  discussed  in  7.4.3  above. 
Guidance  is  therefore  similar. 

GUIDANCE: 

7.4.4.1  Raw  Data  Source  Not  an  AIS  function,  but  where  the  raw  data  is  processed  is  a  separate 
issue.  As  guidance,  store-unique  (type  or  location)  processing  should  be  in  the  store  and 
aircraft  unique  processing  should  be  in  the  aircraft  if  possible.  Only  processing  generic  to  all 
MIL-STD-1760  stores  should  be  in  the  AIS. 


144 


7.4.4.2  Unique  to  User  Formatting  This  is  an  AIS  function  if  the  user  is  another  store,  but 
Should  be  an  aircraft  function  if  the  user  is  the  aircraft.  In  practice  the  aircraft  user  might  be 
the  same  subsystem  sourcing  data  in  a  non-MIL-STO-l  760  format.  The  AIS  is  the  best  location 
for  such  bidirectional  reformatting  (see  also  7.4.3). 

7.4.4.3  Recomputation  to  User  Axes  As  discussed  in  7.4  3.4  the  store  ICD  will  determine  where 
this  function  is  implemented  but  ideally  it  should  be  executed  by  the  store. 

7  4.4.4  Interface  with  Avionics  An  AIS  function  as  this  is  part  of  the  AIS-Aircraft  interface. 

7.4.5  Store  Sfllgctipn 

ISSUE;  Definition  of  the  store  selection  functions  performed  by  the  AIS. 

BACKGROUND:  Store  selection  is  the  function  that  transfers  stores  into  a  Ready  for  Use'  state. 
GUIDANCE: 

7.4.5.1  Type  Determination  Store  type  determination  during  the  store  selection  process  is  not 
an  AIS  function.  This  should  be  implemented  by  either  direct  crew  decision  or  by  a  threat 
management  system.  The  AIS  may  implement  the  sub-function  of  determining  which  specific 
store  type.  This  could  apply  where  air-to-air  capability  is  the  pilot's  choice,  and  the  AIS 
interprets  range  and  other  data  to  select  missiles  (long  or  shon  range)  or  gun.  Note  also  that  the 
certainty  of  type  determination  can  be  safety  critical. 

7.4.5.2  Station  Determination  This  must  be  an  AIS  function.  The  data  required  for  the  function 
includes  store  types,  store  status,  stores  loadout  and  target/aircraft  location.  The  most  time- 
critical  data  will  be  store  status  and  this  is  already  available  firstly  to  the  AIS. 

7.4.5.3  Number  Selection  How  many  stores  are  selected  is  mission  state  dependent  and 
therefore  is  not  an  AIS  function.  The  crew  or  threat  management  system  are  the  best  systems  for 
determining  this  parameter.  Note  that  the  certainty  of  the  number  selection  is  a  critical 
function. 

7.4. 5.4  Store  Initialization  Management  Store  selection  will  frequently  require  more  than  an 
ON/OFF  demand.  Many  current  and  projected  stores  implement  complex  internal  functions  such 
as  inertial  navigation  systems  (INS).  These  systems  require  considerable  quantities  of  data  over 
periods  of  time  before  the  store  is  'Ready  for  Use'.  In  most  cases  that  data  will  already  be 
managed  by  the  AIS,  and  therefore  the  management  of  the  store  processing  of  that  data  is  best 
executed  by  the  AIS. 

7.4. 5. 5  Release  Package  Retention  It  is  common  for  aircrew  workload  to  be  reduced  by  pre¬ 
programming  detailed  store  usage  parameters  into  the  aircraft.  (This  can  be  by  air  or  ground 
crew.)  This  data  is  generically  known  as  a  Release  Package,  and  is  usually  recalled  when  needed 
by  single  switch  or  voice  action.  The  data  can  be  extremely  complex  and  while  only  a  subset  is 
usually  presented  to  the  aircrew,  the  full  data  content  has  to  be  transferred  to  the  stores.  For 
these  reasons  the  AIS  is  the  best  system  to  retain  Release  Package  data.  Other  candidate  systems 
are  the  Display  System  or  the  Stores  Management  System  if  this  is  separate. 

7.4.6  Store  Arming 

ISSUE:  Definition  of  the  store  arming  functions  performed  by  the  ALS. 
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BACKGROUND:  Store  Arming  is  a  safety  critica  function  not  applicable  to  non-weapon  stores. 
An  armed  store  will  detonate  after  release,  whereas  a  non-armed  store  will  not.  Store  fuzing  is 
the  setting  of  the  mode  in  which  an  armed  store  will  be  employed,  for  example  burst  height,  and 
can  therefore  only  be  regarded  as  safety  critical  where  a  mode  inappropriate  to  the  employment 
has  been  inadvertently  set.  Currently,  two  prime  methods  of  store  fuzing  are  implemented, 
namely: 

a  Air  Force  -  Preset  on  the  ground,  either  by  fitting  the  appropriate  fuze  or  manually 

b.  Navy  •  Set  in  the  air,  by  the  transmission  of  an  analog  voltage.  Typically  ±  300V  DC 
or  ±_  195V  DC,  in  the  form  of  a  low  current  pulse  discharged  from  a  capacitor. 

GUIDANCE: 

7.4.6.1  Fuzing  Mode  Determination  This  is  not  an  AIS  function  Although  six  fuzing  modes  are 
defined  in  MIL-STD-1760  (Impact,  Time,  Altitude/Depth,  Proximity,  Position  and 
Interference),  the  selection  of  which  modes  are  applicable  is  mission  dependent  and  therefore  a 
crew  (ground  or  air)  function.  The  determination  can  be  by  preselection  (See  7.4.5.5  above). 

7.4.6.2  Arming  Implementation  This  is  not  an  AIS  function.  The  final  arming  execution 
(detonation  or  non-detonation)  is  executed  by  the  stoie  on  lanyard  removal  and  this  therefoie 
implements  arming. 

7.4.6.3  Armlno/Fuzino  Management  This  should  be  an  AIS  functio  n  The  crew  will  determine 
whether  arming  should  be  generally  enabled  or  disabled.  The  AIS  translates  that  general 
command  into  the  specific  formats  defined  in  MIL-STD-176C. 

7.4.6.4  Fuzing  Times/Distance  Computation  This  shouid  be  an  AIS  function  where  aircraft 
safety  and  target  penetration  are  affected.  MIL-STO-1760  defines  the  formats  for  fuzing  time 
transfer,  although  as  yet  few  projected  stores  have  the  ability  to  use  the  fuzing  time  data.  The 
AIS,  once  preset  with  fixed  aircraft  clearance  and  target  data,  is  best  placed  to  recompute  fuzing 
times  from  aircraft  velocity  and  height  data  duririg  the  mission.  For  data  associated  with  area 
denial  or  burst  height/depth  the  data  should  be  computed  outside  the  AIS. 

7.4.7  Store  Release 

ISSUE:  Definition  of  the  Store  Release  functions  performed  by  the  AIS. 

BACKGROUND:  Store  "release”  is  a  function  implemented  by  the  aircraft  Stores  Management 
System  (SMS).  The  issues  addressed  in  this  paragraph  are  essentially  more  detail  on  one  issue: 
Should  the  SMS  and  the  AiS  be  the  same  system?  The  early  issues  of  MIL-STD-1760  presumed 
this  to  be  the  case,  and,  as  discussed  in  7.3  above,  it  is  easier  for  many  implementations  if  this 
is  so.  The  Implementor,  particularly  when  retrofitting  MIL-STD-1760  to  existing  aircraft, 
should  consider  this  issue  fulV  as  It  may  be  advantageous  to  retain  a  separate  SMS.  Where 
separate  AIS  and  SMS  are  Impiemeuted,  a  tightly  coupled  interface  will  be  required  between  the 
two  systems. 


GUIDANCE: 

/.4.7.1  ReleasB/Launch/Ftra  Prompt  This  is  not  an  AIS  function  as  the  aircrew  must  have 
c-^nirol  over  this  function.  Detailed  interpretation  of  these  prompts  can  be  an  AiS  function,  or 
even  an  AlS/Stoib  hjdCtion  where  execution  depends  on  acquiring  a  target  after  the  crew  prompt 
(Weapon  Release  or  Trigger). 
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7.4.7.2  Suspension  Equipment  Management  This  should  be  an  AIS  function.  The  store 
suspension  equipment  (ejector  rack.  rail,  launchers  etc)  will  require  control  from  the  aircraft 
SMS  function  to  initiate  or  enable  store  Separation.  In  many  cases  this  control  will  depend  on 
store  state  and  target  data  received  by  the  AIS  from  the  store.  Interfacing  and  timing  can  be 
optimized  if  the  AIS  implements  the  SMS.  In  implementing  MIL  STD-1760  the  AIS  will  already 
have  a  critical  data  bus  (1  in  100,000  hours  critical  error  rate),  and  will  be  able  to  command 
store  arming,  release  and  jettison  via  the  data  bus  and  release  consent  signals.  The  AIS, 
therefore,  is  already  implementing  the  same  design  features  required  to  manage  suspension 
equipment,  eject  cartridge  fire  and  rack  unlock  functions. 

7.4. 7.3  Weapon  Bav  Management  This  function  is  required  where  aircraft  have  internally 
carried  stores.  During  release  preparation  weapon  bay  doors  wilt  need  opening,  suspension  and 
release  equipment  may  need  to  be  repositioned  and  achievement  of  both  verifled  before  store 
release.  As  such  these  are  clearly  functions  associated  with  the  SMS  and  should  only  be  an  AIS 
function  if  it  is  implementing  the  SMS. 

7.4.7.4  Separation  Management  Separation  management  is  the  control  of  all  AEIS  and  other 
functions,  such  as  arming  solenoids,  during  the  store(s)  separation  and  the  prevention  of 
separation  when  not  demanded.  As  considered  in  7.4.7.2  above,  this  should  be  an  AIS  function 
only  if  the  AIS  implements  the  SMS. 

7.4  7.5  Separation  Timing  This  is  an  AIS  function  only  if  the  AIS  implements  the  SMS  function. 
Separation  timing  is  the  computation  and  implementation  of  precise  times  of  Separation.  This  is 
more  relevant  where  stores  have  no,  or  primitive,  terminal  guidance.  Separation  timing  has 
traditionally  been  implemented  by  a  Fire  Control  Computer  calculating  times  from  Separation 
mode,  aircraft,  air  and  store  ballistic  data.  Three  factors  will  lead  to  this  separate  fire  control 
computer  function  disappearing.  These  are  the  trend  towards  integrated  processing,  the 
increasing  importance  of  specific  store  station  data  in  calculating  separation  timing,  and  the  AIS 
having  access  to  most  of  the  required  data  to  implement  the  function  without  any  additional  data 
bus  transfers  being  required. 

7.4. 7.6  Impact  Point  Determination  Impact  points  for  stores  can  be  specified  by  position; 
designation,  for  example  laser;  or  characteristics.  The  top  level  determination  of  impact  point  is 
a  critical  function  and  must  be  determined  by  crew.  This  is  therefore  not  an  AIS  function. 

7.4. 7.7  Separation  Sequence  Determination  This  is  an  SMS  function  that  should  probably  be 
implemented  in  the  AIS.  The  sequence  of  multiple  store  separations  will  depend  on  many  factors 
including  determination  of  store  presence  and  status.  MIL-STD-1760  data  bus  and  interlock 
data  will  be  pari  of  this  information  which  also  includes  S&RE  weapon  loaded  monitors  and 
therefore  the  AIS  is  a  prime  system  for  this  function,  if  a  separate  SMS  is  not  implemented. 

7  4.7.8  Hano-llp  Detection  Similar  to  Separation  Sequence  this  should  be  an  AIS  function 
because  of  the  store  presence  data  (Interlock,  data  bus)in  MIL-STD  1760.  Hang-ups  (or  store 
misfires)  can  also  be  caused  by  failure  of  stores  to  receive  correctly  the  MIL-STD-1760  firing 
data,  and  therefore  close  coupling  between  the  AIS  and  hang-up  detection  functions  will  be 
required. 

7  4.7.9  Balance  Management  Balance  management  is  the  function  of  selecting  stores  for 
separation  in  such  a  sequence  that  aircraft  balance  constraints  are  not  exceeded.  Balance 
constraints  can  be  lateral  or  longitudinal  or  both.  Because  of  the  importance  of  the  hang-up 
detection  to  this  function  this  should  also  be  implemented  in  the  AIS  provided  the  AIS  also 
implements  the  SMS  function.  It  Is  possible  that  individual  store  weight,  potentially  identifiable 
by  the  AIS  through  store  type  data,  can  be  used  to  enhance  execution  of  this  function. 
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7.4.7.10  Engine  Control  Assistance  Military  aircraft  engines  can  be  disturbed  or  even  stopped 
by  the  exhaust  gas  from  powered  missile  releases.  Two  techniques  have  been  applied  to  reduce 
this  problem.  Either  the  engines  are  automatically  ’throttled  back*  during  missile  firing  (by 
the  engine  management  system  receiving  a  signal  from  the  AIS  or  other  system)  or  the  missile 
motor  can  be  programmed  to  delay  firing  until  clear  of  the  aircraft  (see  MIL-STD'1760A  data 
entity  0507).  The  use  of  excessive  times  for  engine  'throttling  back'  or  motor  fire  delay  could 
be  severely  degrading  to  mission  success,  and  therefore  if  a  separate  SMS  is  not  implemented  the 
AIS  is  the  best  location  for  this  function. 

7.4.8  Store  Jettison 

ISSUE:  The  definition  of  the  Store  Jettison  functions  that  are  implemented  by  the  AIS. 

BACKGROUND:  Store  jettison  is  similar  to  a  ’release’  function  implemented  by  the  aircraft 
Stores  Management  System  (The  guidance  in  this  paragraph  does  not  restate  the  SMS  guidance  of 
paragraph  7.4.7). 

GUIDANCE: 

7.4.8. 1  Jettison  Prompt  Must  be  under  aircrew  control,  therefore  it  is  not  an  AIS  function. 

7.4. 8.2  Selective  Jettison  Management  This  includes  Suspension  and  Release  Equipment 
Management  and  Weapon  Bay  Management.  If  suspension  equipment  management  is  implemented 
in  the  AIS  then  so  should  selective  jettison  management.  Another  relevant  factor  is  the 
requirement  for  some  stores  to  have  dassined  data  erased  prior  to  jettison.  This  erase  process 
will  be  commanded  by  the  AIS  via  the  MIL-STD-1760  data  stubs,  and  stores  not  thus  deared 
should  be  prevented  from  being  selectively  jettisoned. 

7.4.8.3  Emergency  Jettison  Management  Similar  to  Selective  Jettison,  this  function  should 
probably  be  implemented  by  the  AIS. 

7.4.8  4  Store  Safe  Verification  Stores  should  normally  be  jettisoned  unarmed  (safe).  For 
MIL-STD-1760  stores  this  should  be  effected  by  data  bus  command  prior  to  jettison,  as 
disabling  of  release  consent  may  either  not  disable  arming  or  may  disable  the  jettison.  This 
forces  a  dose  link  between  the  AIS  and  the  safe  before  jettison  function.  It  is  therefore  best 
located  in  the  AIS. 

7.4.9  Inventory 

ISSUE:  Definition  of  those  aspects  of  Store  Inventory  Management  implemented  by  the  AIS. 
GUIDANCE: 

7.4.9.1  Inventory  Determination  Inventory  determination  is  a  critical  function.  If  the  store 
loadout  is  not  correctly  known  then  store  misfiring,  or  even  aircraft  loss  can  result.  Inventory 
of  MIL-STD-1760  Stores  can  be  determined  in  two  ways.  The  first  method  is  for  the  crew  (air 
or  ground)  to  enter  data  detailing  the  inventory.  The  second  method  is  for  the  AIS  to  use  the  store 
description  data  to  identify  the  loadout.  The  MIL-STD-1760  data  approach  has  several  potential 
failure  mechanisms  that  coukJ  result  in  incorrect  inventory  and  therefore  the  crew  should  be  the 
prime  source  of  inventory  data.  This  can  be  implemented  via  an  inventory  panel,  mission 
briefing  data  or  direct  cockpit  entry.  This  function  should  therefore  not  be  implemented  by  the 
AIS. 
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7.4.9.2  Inventory  Confirmation  An  inventory  confirmation  function  is  often  implemented 
because  of  the  importance  of  correct  inventory  determination.  This  compares  the  crew  declared 
inventory  with  suspension  equipment  monitors  and  store  signals.  Discrepancies  are  reported  to 
the  crew.  This  function  is  best  implemented  in  the  AIS  due  to  the  precise  store  type  data 
available  via  the  MIL-STD-1760  store  description  data.  Other  candidate  locations  are  the  SMS, 
if  a  separate  system,  and  the  display  system. 

7  4.9.3  Inventory  Update  during  Mission  The  store  inventory  changes  throughout  a  mission  as 
stores  are  released  or  declared  hung  or  declared  failed.  Both  the  SMS  and  AIS  functions  need  an 
updated  inventory  data  base  to  ensure  correct  actions.  The  AIS  through  Interlock  and  store 
monitor  data  has  significant  information  to  provide  to  this  function.  The  function  should 
therefore  be  implemented  in  either  the  SMS  or  both  the  AIS  and  SMS. 

7.4.10  Crew  Interface 

ISSUE:  Definition  of  the  aspects  of  the  crew  interface  implemente  >;  the  AIS. 

GUIDANCE: 

7.4.10.1  Displays  Displays  are  a  non-AIS  function.  In  modern  military  aircraft  there  are  few 
dedicated  displays,  and  a  dedicated  AIS  display  panel  of  any  size  would  be  inefficient  for  cockpit 
space  and  crew  workload. 

7.4.10.2  Critical  Controls  Critical  controls  are  inputs  such  as  Master  Arm,  Jettison,  Trigger, 
etc.,  which  provide  prompts  to  critical  SMS  and  AIS  functions  such  as  Arming  and  Separation.  It 
is  unlikely  that  the  MIL-STD-1760  data  integrity  requirements  can  be  achieved  unless  these 
controls  directly  interface  to  the  AIS,  and  so  they  should  be  considered  as  part  of  the  AIS.  It  is 
likely  that  they  will  be  implemented  as  part  of  the  aircraft  but  the  AIS  guidelines  will  still 
apply. 

7.4.10.3  Non-Critical  Controls  Similarly  to  displays,  there  is  little  cockpit  space  available  in 
modern  military  aircraft  in  which  to  provide  dedicated  AIS  controls.  The  non-critical  controls 
such  as  select,  target,  etc.,  should  therefore  be  shared  with  other  functions  and  should  not  be 
part  of  the  AIS. 

7.4.11  Nuclear  Control 

ISSUE:  Definition  of  those  aspects  of  Nuclear  Weapon  Control  implemented  by  the  AIS. 

BACKGROUND:  There  are  no  current  MIL-STD-1760  nuclear  stores.  An  interface  specification 
for  nuclear  stores  based  on  MIL-STD-1760  is  being  developed  (System  2). 

GUIDANCE; 

7.4.1 1.1  Suspension  and  Release  Equipment  fS&REt  Similar  to  conventional  stores  discussed  in 

7.4.1  above,  the  suspension  equipment  is  an  aircraft  function  and  not  an  AIS  function. 

7.4.11.2  S&RE  Management  Similar  to  conventional  stores  discussed  in  7.4.7  above,  S&RE 
management  could  be  an  AIS  function  because  of  the  detail  interfacing  required  with  store  status 
data.  The  impact  of  this  function  on  the  AIS  would  be  very  significant  due  to  the  extra  integrity 
required,  and  this  would  in  effect  be  an  addition  of  a  separate  nuclear  system  additional  to  the 
AIS.  As  such  this  should  be  a  non-AIS  function  unless  a  combined  AIS/SMS  is  implemented. 

-3  PAL  Code  Provision  A  crew  function  hence  non-AIS.  The  AIS  will,  however,  transfer 
the  data  to  the  store. 
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7.4.11.4  Two  Person  Action  This  function  should  be  a  non-AIS  function  as  it  relates  to  cockpit 
layout,  organizational  procedures  and  other  criteria  not  relevant  to  provision  of  a 
MIL-STD-1760  nuclear  AIS. 

7.4.11.5  Crew  Controls  Crew  controls  for  data  demanded  by  the  nuclear  interface  (arming, 
codes,  functions)  will  require  careful  design  to  ensure  high  integrity  is  retained.  These  should 
therefore  be  an  AIS  function. 

7.4.11.6  Crew  Displays  Similar  to  crew  controls,  the  displays  of  data  relevant  to  the  nuclear 
interface  should  be  an  AIS  function  to  retain  integrity. 

7.5  Future  Growth  Potential 

ISSUE:  What  future  growth  potential  is  required  by  the  AIS? 

GUIDANCE:  The  history  of  aircraft  and  their  internal  systems  shows  that  modifications  are 
continually  needed  to  change  the  "currenr  design  to  match  new  requirements.  For  the  AIS  these 
changed  requirements  will  be  of  two  forms:  added  (or  changed)  functions,  higher  (or  amended) 
performance  of  those  functions.  Paragraphs  7.1  -  7.4  have  considered  the  functions  that  the  AIS 
should  implement.  It  would  be  difficult  to  provide  meaningful  guidelines  for  changes  in  the 
functionality  of  an  AIS  as  the  aircraft  changes  that  prompt  this  will  be  too  aircraft  specific  for 
general  guidance  to  be  given.  Section  8  considers  the  performance  required  of  each  function  and 
outlines  potential  growth  requirements.  Specific  expansion  provision  requirements  are  defined 
in  8.3.1. 

7.6  Summary  This  section  (7)  has  considered  the  functional  boundary  of  the  AIS.  As  itemized 
below,  a  set  of  AIS  core  functions  and  a  set  of  AIS  probable  functions  have  been  determined. 

AIS  CORE  FUNCTIONS 

MIL-STO-1760  ASI  IMPLEMENTATION 

STORE  STATE  COMMAND  &  MONITOR 

POWER  SUPPLY  MANAGEMENT  FOR  MIL-STD-1760  STORES 

DATA  r^TERFACESTO  STORE 

INTERFACE  WITH  OTHER  AVIONICS 

MIL-STO-1760  STORE  INITIAUZATION  MANAGEMENT 

MIL-STD-1760  STORE  ARMING^FUZING  MANAGEMENT 

MIL-STD-1760  STORE  SAFETY  VERIFICATION 

AISPRQBABLSFUNCTtQNS 

EXISTING  STORE  INTERFACE  IMPLEMENTATION 
UNKXJE  TO  STORE  DATA  REFORMATUNQ 
UNIQUE  TO  STORE  AXES  RECOMPUTATION 
UNIQUE  TO  AVIONICS  DATA  REFORMATTING 
STORES  MANAQB40IT  SYSTEM  FUNCTIONS: 

SELECTION 

ARMING 

RBEASE 

JETTISON 

WVeiTORY 

CRITICAL  CONTROLS  (MASTER  ARM,  TRIGGER  etc) 

NUCLEAR  WEAPON  SMS  FUNCTIONS  (IF  REQUIRED) 
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8.  AIS  SYSTEM  PERFORMANCE  ISSUES  AND  GUIDELINES 


This  section  discusses  those  issues  which  relate  to  the  performance  definition  of  the  AIS.  The 
guidance  given  relates  to  generic  AIS  implementation  and  may  differ  from  other  general 
requirements  of  specific  programs.  In  such  cases  the  higher  of  the  two  requirements  should 
apply.  The  following  major  paragraphs  are  included: 


Approach  to  AIS  performance  definition  8.1 

Performance  factors  associated  with  each  function  defined  in  section  7  8.2 

Performance  factors  associated  with  other  characteristics  such  as  reliability,  8.3 
physical  and  environmental  factors 

AIS  System  interfaces  with  the  stores,  aircraft  and  crew  8.4 


8.1  Approach  to  AIS  Performance  Definition 

ISSUE:  The  approach  to  definirtg  system  performance  parameters 

BACKGROUND;  Section  7  has  considered  the  determination  of  those  functions  that  should  be 
included  in  the  AIS.  The  next  level  of  AIS  definition  is  to  define  the  performarx:e  for  each  AIS 
function. 

GUIDANCE;  Specifying  the  performance  of  a  function  can  be  executed  generically  by  specifying 
factors  such  as; 

a  Inputs 

b.  Outputs 

c.  Input-Output  dependency 

d.  Execution  timing 

e.  Assurance  of  execution 

These  factors  can  be  mapped  on  to  all  of  the  AIS  functions.  It  is  more  helpful,  however,  if  a  more 
specific  to  function  definition  of  performance  can  be  used,  these  are  described  in  the  subsequent 
subparagraphs.  Most  detail  is  specified  for  those  functions  determined  as  core  AIS  functions. 

8.2  AIS  Functional  Performance  This  paragraph  contains  paragraphs  8.2.1  through  8.2.11. 
These  provide  performance  guidance  for  the  corresponding  functions  of  paragraphs  7.4.1 
through  7.4.11. 

8.2.1  Store  Interface  Performance 

8.2.1. 1  MlL-STD-1760  ASI 

ISSUE:  How  should  the  performance  of  MIL-STD-1760  ASI  be  specified  for  the  AIS. 

GUIDANCE:  The  key  performance  characteristics  are  the  number  of  ASis,  the  category  of  ASI 
implemented  at  each  station  and  the  total  aircraft  capacity  required  (in  terms  of  how  many  used 
at  one  time).  Detail  characteristics  such  as  total  data  rates  and  networking  are  discussed  in  later 
sections. 

8-2.1. 1.1  Number  of  ASts  This  is  dependent  on  the  total  weight  capftoility  of  the  air  vehide,  the 
mission  roles  supported  and  the  layout  of  store  stations.  The  type  A  system  specification 
considered  this  issue  and  identified  6  aircraft  types  with  6  mission  types  and  conciuded  that 


151 


between  7  and  32  ASI  were  required.  This  data  is  repeated  in  table  8-1 .  OuidaiKe  is  therefore  to 
first  define  the  aircraft  mission  roles  and  number  of  primary  weapon  carriage  points.  A 
minimum  of  one  ASI  per  weapon  carriage  point  should  then  be  implemented  with  consideration 
given  to  two  or  more  at  weapon  carriage  points  with  potential  for  multiple  carriage  of 
sophisticated  weapons. 

8.2.1. 1.2  ASI  Categories  Some  background  information  is  required  in  order  that  the  guidance  is 
better  understood.  MIL-STD-1760  allows  4  classes  of  ASIs: 

a  I  -  Full  Signal  Set  of  Primary  Interface  only 

b.  lA  -  Primary  and  Auxiliary  Interfaces 

c.  II  -  Primary  Interface  minus  HB2  and  HB4  and  both  the  fiber  optic  and  270V  DC 
provisions 

d  HA  -  Class  II  plus  the  Auxiliary  Interface 
Three  areas  of  guidarrce  are  therefore  given,  namely; 

a  Class  II  ASIs  are  the  minimal  com;;^iant  interfaces.  All  ASIs  six>uld  be  at  least  of  this 

type 

b.  Contact  and  cabling  provision  should  be  made  to  upgrade  two  external  fuselage  stations 
(if  available)  to  class  I  interfaces 

c.  270  Voh  provision  should  be  limited  to  contact  and  cabling  provision  for  those 
aircraft  projected  to  implement  a  270  Volt  power  system 

8.2.1. 1.3  Total  Aircraft  Capacity 

ISSUE:  How  many  ASI  should  be  available  for  simultaneous  use. 

BACKGROUND:  The  AIS  complexity  and  cost  will  not  be  proportional  solely  to  the  number  of  ASI 
implemented.  Data  Bus  rates  and  processing  toads  will  as  examples  be  nx>re  dependent  on  the 
maximum  number  of  ASI  actually  in  use  at  one  time.  This  will  have  further  detail  such  as:  the 
number  of  ASIs  connected  to  stores  at  one  time,  the  number  of  stores  powered  at  one  time,  and  the 
number  of  stores  actively  in  use  at  one  time. 

GUIDANCE; 

a  All  ASIs  should  be  simultaneously  connectable 

b.  The  AIS  should  provide  for  the  maximum  number  to  be  simultaneously  powered 
within  the  constraints  of  available  power  (A  typical  limit  for  stores  consuming  full  power  might 
be  four  ASIs) 

c.  The  AIS  should  be  capable  of  actively  controlling  a  minimum  of  two  ASIs 
simultaneously. 

8.2.1. 2  MIL-STD-176Q  MSI  No  performance  relevant  to  AIS  (not  an  AIS  function) 

8.2.1. 3  Non-AEIS  Signals  (Existing  Store  Interfaces) 

ISSUE:  How  should  the  performarKse  of  Non  AEIS  Signal  Interfaces  be  speofied  for  the  AIS? 

GUIDANCE:  Similar  to  MIL-STD-1760  ASI  the  key  performance  characteristics  are  the  number 
and  locations  of  existing  store  interfaces.  Each  existing  store  interface  type  unique  and 
categories  of  Interfaces  do  not  as  such  arise.  AIS  performance  is  limited  to  the  number  of  non- 
AEiS  interfaces,  their  location  arnf  the  aircraft  capacity  to  simultaneously  utilize  multiple 
stores. 
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TABLE  8-1  Store  Loadout  Configurations  {From  Type  A  System  Specification) 


Numbers  Of  Store  Types  &  Interfaces 


Interceptor  Combat 


Ground  Attack 


Defense  Suppression 


RECCE 


Tactical  and 
Strategic  Bomber 


IBQGB 

&□□□ 

[QD 
llif^ 
mm 

EBBBBEaBBBEEBBBBBB 
OBBBBBBBBGDBBBDB 
RBQBBBaBBBBQaBflfl 
EBBBBaBBBBBBQBD^I 
IBBBBBQBBBBBBBBB^I 
DBBBBBBBBBBBBaflBB 
IRIEIBBBBBI^BBBBBBBF:: 
E^B  B  B  BBdlEBBB  El  BBB 
lElDBBBBBBBg^BBBBBi!!! 


V  •— 

o  eo 

c/> 


II  ^ 


12  I  18  24 


13  I  17  I  21 


11 

BSIBB 

13 

19 

25 

11 

20 

27 

10 

18 

24 

18 

20 

22 

19 

25 

10 

1^ 

■fl 

26 

BOi 

mm 

IMKltlBVlBM 

ibubh 


14  I  18 


MISSIONS: 

A.  Long  Range  Nuclear 

B.  Long  Range  Tactical 
Bombing 

C.  Counter  Air 

D.  Close  Air  Support  / 
Baukneld  Interdiction 

E.  Air  Interdiction 

F.  Reconnaissance 


STORES  (Abbreviations  used) 

AAM  Air-io-Air  Missile 
ACM  Air-to-Cround 
Missile 

W  Nuclear  Store 
ASI  Aircraft  Sution 
Interface 

CSSl  Carriage  Store 
Station  Interface 


NOTE. 

Nuclear  Stores  arc  not 
carried  on  Multiple 
Carriage  Stores 

*  8  Bombs  on  me 
Carriage  Store 


a  Number  of  non-AEIS  Interfaces.  This  should  be  severely  restricted  to  minimize  costs. 
No  general  provision  of  interfaces  should  be  implemented  without  firm  operational  requirements 
as  it  is  unlikely  that  the  store  loadout  will  exparuJ  for  non  MIL-STD-1760  Stores. 

b.  Location  of  non  AEIS  Interfaces.  To  maximize  the  number  of  potential  loadout 
configurations  for  greater  mission  roles  it  is  preferable  to  distrtoute  interface  types.  For 
example  each  station  could  support  a  different  existing  store  type,  ^me  other  general  guidelines 
are:  Provide  dedicated  “wet"  stations  for  fuel  tanks  (if  separable  fuel  tar4(S  are  fitted)  and  avoid 
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provision  of  complex  existing  store  interfaces  at  those  stations.  This  is  because  on  long  missions 
the  aircraft  will  have  fuel  tanks  fitted.  Any  complex  interface  provision  (such  as  HARM, 
Harpoon)  at  the  "wer  stations  will  be  wasted  because  only  a  simple  fuel  tank  wW  be  carried 
there.  Provide  existing  store  interfaces  for  heavier  stores  near  to  the  aircraft  natural  center  of 
gravity.  Where  a  central  interface  is  implemented,  provide  complex  existing  store  interfaces  on 
fuselage  stations,  rather  than  wing  statiorts,  in  order  to  enable  wiring  to  be  reduced. 

c.  Aircraft  Capacity  It  is  beyond  the  scope  of  this  document  to  provide  detail  guidelines 
for  aircraft  capacity  for  non  MIL-STD-1760  stores.  It  is  possbie  to  re^  across  much  of 
the  previous  guidance  to  these  stores  by  assessing  the  relevant  interface  characteristics. 

8.2.1 .4  Suspension  This  is  not  an  AIS  function.  Relevant  data  on  S  &  RE  management  is  included 
in  paragraph  8.2.7. 

8.2.1 .5  Post  Launch  Interfaces  These  are  not  AIS  functions. 

8.2.2  Store  State  Performance  can  only  be  specified  for  critical  stale  changes  because 
MIL-STO-1760  provides  no  starKtardization  of  other  state  definiticns  or  control/monitor 
formats. 

8.2.2.1  State  Change  Prompt 

ISSUE:  What  are  the  performance  requirements  of  the  AIS  in  determining  state  change  prompts. 

GUIDANCE:  As  discussed  in  7.4.2.1  most  state  change  prompts  are  initiated  outside  of  the  AIS. 
Two  possible  exceptions  (dependirtg  on  interpretation)  are  store  failure  and  store  separation: 

a  Store  Failure:  On  detecting  that  a  store  has  failed  the  AIS  should  set  that  store  to  the 
least  active  safe  state  and  change  the  states  of  other  store<s)  of  that  same  type  to  regain,  if 
possible,  the  previous  situation  in  terms  of  'quantity  of  stores  ready  for  use.'  Should  the  store 
not  have  totaBy  fsuled  and  its  employment  in  a  degraded  mode  is  possible,  then  it  may  be  available 
as  the  last  selected  weapon. 

b.  Store  Release:  On  detecting  that  a  sk>re  has  been  separated,  then  for  most  store  types, 
the  AIS  should  initiate  all  possi}le  reversible  state  changes  to  bdng  another  store  ot  the  same 
type  to  a  stale  of  'ready'  for  separation. 

8  2.2.2  Store  State  Command 

ISSUE:  How  should  the  performance  of  the  AIS  be  specified  for  the  issuing  of  Store  State 
Commands? 

GUIDANCE:  The  performance  will  be  specified  by  inputs,  outputs,  dependency,  timing  and 
execution  assurance. 

a  Inputs  The  key  inputs  are: 
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Critical  Switches 


Master  Arm  (MAS) 

Trigger  (TRIG)  -  o:  Weapon  Release  (WR) 

Selective  Jettison  (SJ) 

Emergency  Jettison  (EJ) 

Cockpit  Disi;>iay  System  IBIT  demand 

Store  selected 

Type  deselected  (SRAAM,  BOMB  &  AGM) 

Jettison  selected 

Store  Current  State 

Long  Term  Select  attribute  (cooling) 

AIS  Store  Hung 

Store  deselected 

Store  next  (for  release  jettison) 

Store  due  (for  release  jettison) 

b.  Outputs  The  key  outputs  are  the  MIL-STD-1760  Mission  Store  Control  message 
(containing  the  Critical  Control  word  and  its  associated  Authority  word)  and  Release  Consent. 
The  AIS  should  ensure  that  these  are  conectly  formatted.  The  relevant  states  of  critical  control 
are  definat<e  by  the  bit  patterns  for  0^0-03  of  the  critical  control  word  and  ReL<ase  Consent. 
Th>'y  are  listed  below. 


Store  states  are: 

Critical  Control 

Release  Consent 

RESET 

0000 

0000 

INHIBIT 

1  BIT 

0000 

0X10 

INHIBIT 

SELECTED 

0000 

0100 

INHIBIT 

PRESET  ARMING 

0000 

1100 

INHIBIT 

EXEClfTEARMING 

0001 

1100 

X 

COMMIT  TO  LAUNCH/EJeCT 

0011 

1100 

ENABLE 

FIRE/LAUNCH/EJECT 

1011 

1100 

ENABLE 

JETTISON 

0100 

0X00 

INHIBIT* 

*  Store  may  require  this  a'so  to  be  enabled. 

c.  Oeoendfincy  The  AIS  should  provide  interlocks  on  the  achievement  of  critical  states. 
As  an  example  Execute  Arming  should  net  be  demanded  unless  Master  Arm  has  been  demanded. 
Table  8-2  details  a  recommerxfed  dependonc7  of  the  defined  inputs  and  outputs.  Sufficient 
ambiguity  exists  in  MIL-STD’1760  such  that  order  certain  conditions  poor  store  design  could 
be  incompatible  with  this  sequence.  Store  project  offices  should  ensure  that  stores:  cannot  fail 
if  they  aro  commanded  to  anv  of  the  store  states  defined  in  b.  above;  format  the  critical  monitor 
data  to  reflect  store  demanded  states. 

d.  Timing  Timing  requirements  for  critical  control  demands  will  depend  on  the  aircraft, 
thvi  store  type  and  mission  phase.  For  example,  demand  of  Commit  to  Separate  will  be  required 
with  extreme  urgency  If  a  bomb  has  just  hung  in  a  separation  sequence  but  less  urgency  is 
required  for  a  missile  where  the  target  data  may  still  be  unavailable.  For  these  reasons  the 
specific  timing  performance  should  be  embedded  into  the  SMS  functional  requirements  related  to 
specific  mission  needs  for  stores  management.  Because  the  AIS  may  be  a  separate  entity  from  tne 
SMS  the  following  minimum  AIS  performance  is  required:  changes  in  State  requiring  change  of 
any  data  bit  D^g-Ds  of  the  MIL-STD-1760  crit'cal  control  word  must  be  communicated  to  the 
store  within  BOmS  of  the  input  conditirr*?  assuming  the  required  states;  other  changes  of  state 
wiihin  10  seconds. 
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TABLE  8-2  MIL-STD-1760  STATE  DEMANDS 


IF 

& 

& 

& 

NEW  STATE 

STATE  NOW 

Critical  Switches 

CocKpit  Display 
System 

AIS 

RESET 

ANY- 

X 

X 

Store  Huno 

or 

X 

X 

Store  Deselect 

or 

X 

Store  Deselected 

X 

•or 

X 

Tvoe  Deselected 

X 

l-BIT 

RESET 

AaSAFE 

Type  Deselected 
&  l-BIT  demand 

Not  hung 

SELECT 

RESET 

X 

Type  Selected 

neither  hung  nor 
deselected 

PRESET  ARMED 

SELECT  or  RESET 

Type  Selected 

neither  hung  nor 
deselected 

EXECUTE  ARMED 

PRESET  ARMED 

Type  Selected 

neither  hung  nor 
deselected 

COMMIT  to 
LAUNCH 

EXECUTEARMED 
or  PRESET 

ARMED 

MAS  »  LIVE  & 
TRIG  or  WR  - 
LIVE 

Type  Selected 

Store  Next  to 
Release 

FIRE/LAUNCH 

COMMIT  to 
LAUNCH 

MAS  >  LIVE  & 
TRIG  or  WR  = 

LIVE 

Type  Selected 

Store  Due  to 
Release 

EJECT 

COMMIT  to 
LAUNCH 

MAS  =  LIVE  & 
TRIG  or  WR  = 

LIVE 

Type  Selected 

Store  Due  to 
Jettison 

JETTISON 

AN/ 

SJ and  MAS- 
LIVE  or  EJ 

X 

Store  Next 

X  «  don't  care  *  -■  only  if  store  has  no  long  term  select  attribute  (cooling) 

**  =  RESET  should  not  be  demanded  if  COMMIT  to  LAUNCH  has  been  demanded  unless  a  fault  or  an 
emergency  conditions  arises 


e.  Execution  Assurance  Assuring  for  critical  states  has  the  two  basic  parameters  of 
assuring  the  state  will  be  demanded  when  required  (success)  and  assuring  the  state  will  not  be 
demanded  when  not  required  (safety): 

Success:  Maximum  probability  per  ASI  of  failure  of  this  function  should  be  1  X 
1 0‘^  after  one  mission  houi 

Safety:  Maximum  probabilities  per  AS!  of  incorrectly  demanding  states  should 
be: 

1 0'^  after  one  mission  hour  if  failure  corresponds  to  incorrect 
interpretation  of  Selective  Jettison  or  Emergency  Jettison  as  demanded 

10'^  after  one  mission  hour  if  failure  corresponds  to  incorrect 
interpretation  of  Master  Arm  and  Weapon  Release  as  demanded 


10'^  after  one  mission  hour  if  failure  corresponds  to  incorrect 
interpretation  of  Master  Arm  or  Weapon  Release  as  demanded 
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1 0'^  after  one  mission  hour  for  all  other  cases 

Note  that  for  stores  which  do  not  implement  Release  Consent  as  an  interlock  on  any  state,  the  AIS 
must  provide  the  above  level  of  safety  for  the  data  bus  path  alone.  This  position  is  less  serious 
following  issue  of  MIL-STD-1760A  Notice  3  which  minimally  requires  Release  Consent  as  an 
interlock  on  all  irreversible  critical  functions  excluding  jettison. 

8.2.2.3  Slate  Monitor 

ISSUE;  How  should  the  performance  of  the  AIS  be  specified  for  the  monitoring  of  store  states. 

GUIDANCE:  The  AIS  should  positively  monitor  for  achievement  of  all  demanded  MIL-STD-1760 
slates.  Specifically,  where  no  ICO  data  is  available  to  further  optimize  the  implementation,  the 
MIL-STD-1760  Critical  Monitor  word  should  be  monitored  for: 

a  Correct  demanded  state  within  lOOmS  of  demanding  each  new  state 

b.  Achieved  state,  within  tOOmS  of  demanding  each  new  state,  at  minimum  10Hz,  until 
either  the  state  is  achieved  or  the  store  declared  as  failed 

c.  At  a  minimum  rate  of  0.5  Hz  for  every  store  with  power  applied 

8.2.2.4  Power  Supply  Management 

ISSUE;  How  should  the  performance  of  the  AIS  be  specified  for  MIL-STD-1760  Power  Supply 
Management? 

GUIDANCE:  The  AIS  must  comply  with  all  MIL-STD-1760  requirements  including  Voltage, 
Current  and  Fault  Isolation  at  each  ASI.  In  addition  the  AIS  should: 

a  Ensure  that  power  requirements  for  any  demanded  state  are  provided  bebre  demand  of 
that  state. 

b.  Ensure  that  provisbn  of  energization  of  power  signals  at  MIL-STD-1750  interteces 
is  minimized.  Particular  care  should  be  made  to  avoid  premature  energizatbn  of  28  Volts  2  or 
Auxiliary  28  Volts  and  to  remove  all  power  at  disconnected  interfaces. 

c.  Ensure  that  the  total  simultaneous  power  available  at  MIL-STD-1760  interfaces  is 
compatible  with  missbn  requirements.  As  a  minimum,  any  four  ASI  should  be  able  to 
simultaneously  supply  full  current  capability. 

6.2.3  Data  To  Store  Data  to  store  is  considered  here  as  limited  to:  MIL-STD-1553  data,  High 
Bandwidth  signals,  Low  Bandwidth  signals,  and  Release  Consent.  Address  discretes  and  Power 
supplies  are  considered  to  provide  low  level  information  not  requiring  specific  data  guidelines. 

8.2.3. 1  Store  to  Store  Data  Source  Not  an  AIS  function,  see  8.2.3.5  br  detail  on  networks. 

8.2.3.2  Aircraft  Raw  Data  Source  As  defined  in  seetbn  7,  although  the  aircraft  raw  data  source 
is  not  an  AIS  bnctbn,  the  transfer  of  aircraft  data  and  the  store  specific  data  processing  are  AIS 
functions.  Issues  that  arise  are  therefore: 

a  Data  Formats 

b.  Data  Availability 

c.  Data  Accuracy 
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d  Data  Latencies  and  Update  Rates 


8.2.3.2.1  Data  Formats 

ISSUE:  What  data  formats  should  be  used  for  aircraft  data  received  by  the  AIS? 

GUIDANCE:  All  data  from  aircraft  to  the  AIS  should  be  in  MIL-STD-1760  formats  for  word  and 
entity  definition.  This  only  applies  when  considering  data  formats  for  new  aircraft  equipment. 
The  AIS  should  execute  any  necessary  reformatting  of  data  from  existing  avionic  equipment  (For 
example  the  air  data  computer  may  not  provide  data  in  MIL-STD-ITGO  formats). 

8.2.3.2  2  Data  Availability 

ISSUE:  What  data  types  should  be  available  to  the  AIS? 

GUIDANCE:  The  AIS  should  minimally  make  interface,  processing  and  memory  provision  for  the 
transfer  (with  recomputation  as  required)  of  the  following  MIL-STD-1760  data  entities  from 
aircraft  data:  Fuzing/Arming  data;  Aircraft  System  Time;  Aircraft  Inertial  position  (and 
velocities)  in  latitude/longitude  and  local  XYZ  forms;  Aircraft  to  Store  alignment  data;  and  Target 
position  (and  velocities)  for  up  to  4  targets  from  16  in  latitude/longitude,  local  XYZ.  and  polar 
forms.  Provisions  should  also  be  made  for  an  100%  increase  in  the  above  data.  Where  target 
velocity  data  is  not  available  to  the  AIS  the  AIS  should  provide  processing  to  generate  velocities 
by  rate  change  computation.  This  processing  should  only  be  executed  when  stores  are  being 
targeted  that  can  utilize  the  velocity  data. 

8.2.3.2  3  Data  Accuracies 

ISSUE;  What  accuracy  is  required  for  aircraft  data  transferred  to  and  through  the  AIS? 

GUIDANCE:  The  AIS  should  minimally  provide  compuiational  accuracy  for  the  following  data 
types  as  indicated  in  Table  8-3.  As  an  example  of  an  inaccuracy  calculation,  the  inaccuracy  of 
Target  Velocity  data  received  by  the  store  should  be  maximum  ±2  meters/second.  This  is  the 
sum  of  the  aircraft  and  AIS  inaccuracies. 


Table  8-3  Data  Inaccuracies 


Data  Tvoe 

Aircraft  Error* 

AIS  Inaccuracy 

Fuzing  Timos 

±  ImS 

i.  ImS 

Fuzing  Positions 

±  1  meter 

±  1  meter 

Aircraft  System  Time 

±  2.5mS 

±  2.5mS 

Aircraft  Position 

±,  5  meters 

±  5  meters 

Aircraft  Velocity 

±  0.5  m/second 

±  0.5m/second 

Aircraft-Store  Position 

±  0.1  meter 

±  0.1  ncier 

Aircraft-Store  Angles 

±  0.001  semicircles 

±.  0.001  semicircles 

Target  Position 

±  5  meters 

±  5  meters 

III  11  III 

i  1  meter/second 

±  1  meter/second 

Target  Angles 

±  0.001  semicircles 

±  0.001  semicircles 

*  Aircraft  error  is  an  assumed  figure  and  is  not  a  performance  characteristic  of  the  AIS.  It  is 
quoted  to  provide  an  indication  of  the  inaccuracy  of  data  received  by  the  store  (In  many  cases  the 
supplied  data  will  be  more  inaccurate). 
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8.2.3  2.4  Data  Latencies  and  Update  Rates 

ISSUE:  What  MS  performance  should  be  specified  for  data  latency  and  data  update  rates? 

BACKGROUND:  Data  latency  is  defined  as  the  time  delay  from  data  being  presented  to  the  MS  from 
the  avionics,  to  being  received  by  the  store  via  the  ASI.  Update  Rates  are  defined  as  the  number 
of  times  in  a  set  time  period  that  a  data  type  is  meaningfully  retransmitted  by  the  AIS  to  a  store. 

GUIDANCE:  Maximum  data  latency  and  minimum  update  rate  performance  capable  of  being 
provided  by  the  AIS,  should  be  as  shown  in  Table  8-4  for  the  indicated  digital  data  types.  For 
Analog  Signals  (High  and  Low  Bandwidth)  the  maximum  data  latencies  shown  in  Table  8-5  should 
be  provided. 

TABLE  8-4  Digital  Data  Latencies  and  Update  Rales 


Data  Type 

Maximum  Latency 

Minimum  Update  Rate 

Target  Positions 

100  mS 

20  Hz 

Target  Velocities 

100  mS 

20  Hz 

Aircraft  Positions 

120  mS 

15  Hz 

Aircraft  Velocities 

120  mS 

IS  Hz 

System  Time 

• 

* 

Other  Data 

1  second 

1  Hz 

*  System  Time  latency  is  not  relevant;  see  8.2.3.2  3  for  allowable  data  inaccuracy 


TABLE  8-5  Analog  Data  Latencies 


Signal 

Maximum  Data  Latency 

HB  1 

500  ns 

HB2 

500  ns 

HB3 

20  ms 

HB4 

20  ms 

LB 

20  ms 

8.2.3  3  Unique  to  Store  Formatting 

ISSUE:  What  AIS  performance  should  be  specified  for  the  reformatting  of  aircraft  data  into 
unique  to  store  formats? 

GUIDANCE;  The  AIS  should  as  a  goal  receive  all  aircraft  data  in  MIL  STD-1760  formats 
compatible  with  store  required  formats.  Where  this  is  not  feasible  (because  of  unique  to  store 
formats  or  because  of  retention  of  avionic  equipment  with  other  formats)  then  the  AIS  should 
provide  for  all  required  reformatting  without  exceeding  the  limits  of  accuracy,  latency  and 
update  rate  performance  speciriod  in  8.2.3.2.  Spedal  care  should  be  taken  in  aircraft  and  store 
design  to  avoid  the  need  for  reformatting  of  High  Bandv;idth  signals. 

8. 2.3.4  Recomputalion  to  Store  Axes 
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ISSUE:  How  should  the  performance  of  the  AIS  be  specified  for  recomputation  of  aircraft  data  to 
store  axes? 

GUIDANCE:  As  discussed  in  7.4.3.4.  this  will  probably  be  an  AIS  function.  The  AIS  should 
provide  for  all  required  reformatting  without  exceeding  the  limits  of  accuracy,  latency  and 
update  rate  performance  specified  in  8.2.3.2. 

8.2.3  5  Interface  to  Store  Most  AIS  performance  factors  for  provision  of  MIL-STD-  !760 
interfaces  are  discussed  in  8.2.1.  Additional  performance  factors  discussed  in  this  paragraph 
are:  Analog  network  -  network  paths  provided  and  signal  performance;  Release  Consent  - 
assurance,  timing,  and  isolation. 

8.2.3.5.1  Analog  Network 

ISSUE:  How  should  the  performance  of  the  AIS  be  specified  for  Analog  Networks? 

GUIDANCE:  The  AIS  analog  network  should  comply  with  all  MIL-STD-1760  requirements  for 
implemented  High  Bandwidth  and  Low  Bandwidth  interfaces.  Additionally  the  AIS  should  provide 
the  following  network  and  signal  performance  for  the  signal  interfaces  HB1,  HB2,  HB3,  HB4, 

LB.  Performance  requirements  for  all  signal  types  should  be  simultaneously  available. 

a  HBt/H32  •  The  AIS  should  minimally  provide  the  following  network  performance: 
transfer  of  one  type  6  signal  between  any  one  ASI  and  the  aircraft  (either  direction),  or  transfer 
of  two  type  A  signals  between  any  two  ASI  and  the  aircraft,  or  transfer  of  a  type  A  signal  between 
any  two  ASI  (either  direction)  and  a  type  A  or  B  signal  between  any  other  ASI  and  the  aircraft 
(either  direction). 

b.  HB3/HB4  •  The  AIS  should  provide  the  following  network  performarice:  transfer  in 
either  direction  of  two  type  A  signals  between  any  two  ASI  and  the  aircraft,  or  transfer  in  either 
direction  a  type  A  signal  between  any  two  ASI  and  a  type  A  signal  between  any  other  ASI  and  the 
aircraft. 

c.  In  addition  to  all  MIL  STO-1760  requirements,  the  AIS  shall  limit  type  B  signal 
attenuation  and  noise  such  that  GPS  signals  received  by  the  store  have  a  minimum  0.01  uV  P*P 
amplitude. 

d  LB  -  The  AIS  should  provide  the  following  penormance:  transfer  in  either  direction 
of  a  LB  signal  between  any  ASI  and  the  aircraft. 

e.  In  addition  to  all  MIL  STO-1760  requirements  the  AIS  shall  limit  maximum 
attenuation  to  6dB  for  signals  of  20  Hz  to  1  MHz  passed  between  aircraft  and  store.  The  signal 
path  characteristic  impedance  should  be  78  ohms  ±  10%. 

f.  The  AIS  network  performance  is  shown  in  figure  8-1. 
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FIGURE  8-1  AIS  Analog  Network  Requirements  For  N  ASI 


8.2.3  5.2  Release  Consent 


ISSUE:  How  should  the  performance  of  the  AIS  be  specified  for  Release  Consent? 

GUIDANCE:  The  AIS  Should  comply  with  all  MlL-STD-1760  requirements  for  Release  Ckjnsent 
with  isolation  requirements  interpreted  as  c.  below.  Additionally  the  AIS  should  provide  the 
following  assurance,  timing  and  isolation: 

a  Assurance:  The  AIS  shall  ensure  tttat  the  maximum  probability  of  failure  to  set  the 
correct  stale  for  Release  Consent  is:  10'®  after  one  mission  hour  for  enabling  when  neither 
Master  Arrn  or  Jettison  are  demanded,  compliant  with  performance  specified  In  8.2.2.2.5.  and 
readily  verifiable  by  simple  and  brief  design  analysis  following  modifications  to  any  AIS  non- 
critical  software. 


b.  Timing:  To  satisfy  the  performance  requirements  defined  in  8.2.2.2.d  and 
MIL-STO-1760A  Notice  3,  the  Release  Consent  signal  must  be  enabled  by  the  AIS  within  60  mS 
of  the  AIS  input  conditions  assuming  the  required  states. 

c.  Isolation:  To  clarify  the  Release  Consent  isolation  requirement  so  as  not  to  exclude 
designs  with  BIT  monitors  on  interfaces,  the  AIS  shall  interpret  the  isolation  requirements  of 
MIL  STD-1760  as  follows:  the  steady  state  current  through  a  1  Kohm  load  shall  not  exceed 

5  mA  when  the  interface  Is  in  an  inhibited  state,  and  the  steady  state  current  shall  not  increase 
by  more  than  250uA  when  any  other  Release  Consent  interface  is  enabled. 

8.2.4  Cats,  from  Store  Data  from  Stores  Is  considered  here  to  be  limited  to  MIL-STD-1553, 
High  Bandwidth  and  Low  Bandwidth  data.  Many  AIS  requirements  for  data  from  stores  are 
similar  to  those  defined  for  data  to  stores  in  8.2.3. 
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8.2.4. 1  Raw  Data  Source  As  defined  in  section  7  the  store  raw  data  source  is  not  an  AIS  function 
but  the  transfer  of  the  store  data  is.  Issues  that  arise  are  therefore: 

a  Data  Formats 

b.  Data  Capabilities 

c.  Data  Accuracies 

d  Data  Latencies  and  Update  Rates 

8.2.4.1.1  Data  Formats 

ISSUE:  What  data  formats  should  the  AIS  be  capable  of  receiving  from  stores? 

GUIDANCE:  Where  possible  all  data  from  stores  should  be  in  MIL-STD-1760  fonnats.  It  is 
likely  that  many  divergent  formats  will  be  used  for  store  monitor  data  entities  unless  strong 
project  direction  is  provided.  The  AIS  should  foerefore  be  compatible  with  receiving 
MIL-STD-1760  formats  for  messages  and  words  with  additionally  the  capability  to  process  10 
words  per  store  type  of  unique  to  store  monitor  data  entities. 

8.2.4.1.2  Data  Capabilities 

ISSUE:  What  store  data  types  should  the  AIS  be  capable  of  processing  to  provide  decisions  and 
aircraft  data? 

GUIDANCE:  The  AIS  should  minimally  provide  interface,  processing  and  memory  capacity  for  the 
following  data  entities  from  stores:  Vector  Word,  Store  Identity,  BIT  Times,  Critical  Monitor  1, 
Rounds  remaining,  Tai^et  position  (in  latitude/longitude,  XYZ  or  polar  form).  Store  state  of 
health  data.  Store  position  (in  latitude/longitude  or  XYZ  format  from  INS),  Store  reference 
system  alignment  and  position,  and  an  100%  increase  in  all  of  the  above  data. 

8  2.4.1. 3  Data  Accuracy 

ISSUE;  What  accuracy  is  required  for  data  received  from  stores? 

GUIDANCE:  The  accuracy  of  data  available  from  stores  is  not  a  performance  factor  of  the  AIS. 
However  the  AIS  performance  for  data  reformatting  for  either  aircraft  or  store  end  users  shouid 
be  defined  as  shown  in  Table  8-6. 

TABLE  8-6  Store  Data  Accuracies 


Data  Type 

Maximum  AIS  inaccuracy  foi  env  -er 

Another  Store  l.^ir  .  .'t 

Store  position 

±  5  meters  I  „  5  nr  .  ters 

Store  Velocity 

i.  0.5  m/second 

1  itVsecond 

Target  Angular  Position 

±  5  X  10*^  semicircle  j 

±.0  »  10'3  semicircles 

Target  Position 

±  5  meters 

±.  5  meters 

8.2.4.1.4  Data  Latendes  and  Ltadate  Rales 

ISSUE;  How  should  the  performance  of  the  AIS  be  specified  for  data  latency  and  data  update  rates 
for  data  from  stores? 
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GUIDANCE:  For  store  to  store  transfers  the  AIS  should  provide  performance  as  sp^fied  for 
aircraft  data  in  8.2.3.2.4.  For  store  to  aircraft  data  the  AIS  should  provide  cap^lHy  for  the 
performance  as  shown  in  Table  8-7. 

TABLE  8-7  Store  Data  Latencies  and  Update  Rates 


Data  Type 

Maximum  Latency 

Minimum  Update  Rate 

Target  position 

200  ms 

10  Hz 

Store  Position 

150  ms 

15  Hz 

8.2.4.2  Unique  to  User  Formatting 

ISSUE:  How  should  the  performance  of  the  AIS  be  specified  for  reformatting  of  store  data  to 
match  other  store  or  aircraft  requirements? 

GUIDANCE:  The  AIS  should,  as  a  goal,  receive  all  data  in  MIL-STD-1760  data  formats  compatible 
with  all  MIL-STD-1760  store  and  all  aircraft  equipments.  Where  this  is  not  feasible,  the  AIS 
should  provide  for  all  reformatting  required  for  the  initial  defined  store  loadout. 

8  2.4.3  Recomputaiion  la  User  Axes 

ISSUE:  How  should  the  performartce  of  the  AIS  be  specified  for  racomputation  of  store  data  to 
store  or  aircraft  axes? 

GUIDANCE:  As  described  In  7.4.4.3,  this  will  probably  be  an  AIS  function.  The  AIS  should 
provide  for  all  necessary  axes  conversion  without  exceeding  the  limits  of  accuracy,  latency  and 
update  rate  performance  specified  in  8.2.4.I. 

8.2.4.4  Interface  with  Avionics 

ISSUE:  How  should  the  performance  of  the  AIS  be  specified  for  Store  data  interfacing  with  other 
avionics? 

GUIDANCE:  This  is  provided  in  paragraph  8.4  where  a  clearer  c'efinition  of  avionics  interface 
guidance  is  given. 

8.2.5  Store  Selection  The  AIS  functions  determined  in  paragraph  7.4.5.  are:  Station 
Determination,  Store  Initialization  management,  and  release  data  package  retention. 

8.2.5.1  Station  Determination 

ISSUE:  How  should  the  performance  of  the  AIS  be  specified  for  determination  of  which  stations 
should  have  stores  selected? 

GUIDANCE:  Stations  shoufo  be  selected  set^entiatty  by  the  AIS  in  the  order  that  sfore  separation 
would  best  be  executed.  This  can  vary  with  aircraft  type,  store  type  and  mission  dynamics.  A 
default  set  of  rules  for  sequentialty  selecting  'nexT  stores  as  the  number  selected  increases  is: 

a  The  *nexf  store  mi^t  be  of  the  correct  type  and  not  failed. 
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b.  Assuming  all  other  selected  stores  of  that  type  are  successfully  separated  then  the 
separation  of  the  ‘nexr  store  must  not  violate  balance  constraints,  if  a  pairs  separation  mode  is 
selected  and  the  ’next*  store  will  be  the  second  of  a  pair  then  additionally  the  potential  release 
must  not  violate  balance  constraints  if  the  first  of  the  pair  harigs  up. 

c.  If  the  last  store  selected  is  located  in  a  multiple  store  Weapon  Bay  then  the  next  store 
should  be  from  the  same  bay.  Otherwise  the  *nexf  store  sfx>uld  not  be  from  the  same  station  as 
the  previous  store  selected.  Consideration  should  be  given  that  this  rule  may  require  inverting 
for  weapon  bay  aircraft  so  as  to  minimize  aerodynamic  disturbance  during  release. 

d.  The  'next*  store  should  not  be  from  a  station  adjacent  to  the  previous  store  selected. 

e.  The  ‘next"  store  should  be  from  die  side  of  the  aircraft  nearest  to  the  target. 

f.  The  ‘next’  store  should  be  from  the  Port  side  of  the  aircraft  (this  provides  for  a 
definite  choice  when  two  or  more  stores  satisfy  all  the  other  checks). 

8.2.5.Z  Store  Initialization  Management 

ISSUE:  What  MS  performance  should  be  specified  for  the  store  initialization  management? 

GUIDANCE;  Specific  and  quantitative  guidance  cannot  be  provided  for  this  function  as 
initialization  requirements  are  at  least  in  part  specific  to  store  type.  General  performance 
guidance  is  provided  *or  three  initialization  types;  INS  alignment,  tuning,  and  cooling/run  up. 

8.2.5.2.1  INS  Alignment  The  AIS  should  provide  for  INS  alignment  of  stores.  Typical 
performance  ts  defined  below: 

a  Phases  •  The  alignment  should  be  split  into  coarse  alignment  and  fine  alignment 

phases 

b.  Coarse  alignment  -  During  coarse  alignment  the  AIS  should: 

•  Inform  the  store  that  coarse  alignment  is  required 

-  Transfer  aircraft  velocity  and  aircraft-store  angles,  or 

direction  cosines,  to  the  store.  The  update  rate  may  be  as  high  as  10Hz  for  fast  risetime'  stores 
or  as  low  as  0.2  Hz  for  strategic  missiles. 

•  Coarse  alignment  should  be  terminated  when:  the  store  informs  the  aircraft 
that  coarse  alignment  has  been  achieved,  or  the  AIS  can  monitor  that  the  store  INS  "velocities’ 
are  sufficiently  matched  to  the  aircraft  velocities,  or  the  AIS  can  determine  that  coarse 
alignment  should  be  aborted  (typically  due  to  time  out  of  5  minutes  for  strategic  missiles  or 
shorter  for  tactical  stores) 

•  When  coarse  alignment  has  been  achieved,  fine  alignment  should  be  started 

c.  Fine  Alignment  -  During  fine  alignment  the  AIS  should 

-  Inform  the  store  that  fine  alignment  is  required 

-  Transfer  aircraft  velocities,  position  and  aircraft-store  angles,  or  direction 
cosines,  to  the  store.  The  update  rate  may  typically  be  0.01  Hz  for  strategic  mtesiles. 

•  Fine  alignment  sliould  be  terminated  when  the  store  is  released,  or  the  store  is 
long  term  deselected,  or  the  AIS  ctm  determine  that  fine  alignment  should  be  aborted  because  of 
errors  in  the  store  monitored  velocities  and  positions. 
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8.2.5.2.2  luoiOfl  The  AIS  should  provide  for  some  stores  to  be  tuned  while  initializing.  This 
lunction  will  not  require  active  tuning  by  the  AIS.  as  in  the  existing  Sparrow,  but  the  following 
should  be  impfontented: 

a  Provision  for  stores  to  delay  achievement  of  selection  by  some  seconds  while  tuning  to 
high  bandwidth  signals. 

b.  Provision  of  “alerT  or  re-tune  commands  to  store  when  relevant  high  bandwidth 
signals  change  in  character. 

c.  Provision  tor  stores  to  ’deselect"  while  re-tuning. 

8.2.5.2.3  Coolino/Run  Up  The  AIS  should  provide  for  some  stores  to  rec^ire  lengthy 
initialization  duri^  selectfon.  Examples  of  cun-ent  inventory  stores  with  such  functions  are 
Sidewinder  (cooling  of  seeker)  artd  Harpoon  (heating).  The  following  should  be  implemented: 

a  Provision  for  some  stores  to  delay  achievement  of  selection  by  some  minutes  while 
cooling/running  up 

b.  Avoidance  of  deselection  of  these  stores  even  when  other  stores  are  selected 
(reference  table  8-2  note  2) 

8.2.5.3  Release  Package  Data  Retention 

ISSUE:  What  AIS  performance  should  be  specified  for  the  release  package  retention? 

GUIDAfsiCE:  The  AIS  should  provide  for  a  minimum  of  eight  weapon  packages  to  be  retained  with  a 
further  minimum  of  one  for  each  store  type  loaded.  The  packages  should  be  storerVrecalled  by 
receipt  of  single  word  avionic  data  command.  The  AIS  should  provide  for  the  data  shown  in  table 
8.8  to  be  retained.  Additionally  the  AIS  should  provide  for  specific  to  store  data  and  data  files 
retention  to  be  added  if  required. 


TABLE  8.8  Release  Package  Data 


Data 

Words 

Data  Source 

Notos 

Total  to  Release 

1 

AIRCREW 

Bombs 

Number/Iteration 

1 

ARCREW 

Single/Pair/Salvo 

Meters  Soacina 

1 

CREW 

Bombs.  Distance  (L)  data 

Manual  Spadno  (ms) 

1 

CREW 

Bombs 

Fuzina  Mode 

1 

CREW 

as  MIL-STD-1760 

Fuzing  Distances 

8 

CREW/Avionics 

as  MIL-STD-1760 

Target  Position 

6 

GROUND  LOAD 

XYZ  or  latitude/lonaitude/heiaht 

Trajectory 

24 

GROUND  LOAD 

4  Waypoints 

Target  Description 

16 

JTIDS 

Typicallv  Emission  Data 

Other 

16 

- 

Expansion 

8.2.6  Store  ArminQ/Fu2inn 

ISSUE:  What  AIS  performance  should  be  spedfled  for  the  Store  arming? 
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GUIDANCE:  The  AIS  functions  as  detennined  in  paragraph  7.4.6  are  Arming/Fuzing  Management 
and  Fuzing  Times  Computation.  These  are  further  cSscussed  in  8.2.6.1  •  8.2.6.2. 

8.2.6.1  Armina/Fuzino  Management 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Arming/Fuzing  Management? 

GUIDANCE:  The  AIS  should  control  the  arrrter^safe  status  of  MtL-STD-1760  stores  by 
energizing/de-energizing  the  arming  solenoids  and  implementing  the  store  critical  state  function 
as  defined  in  B2.2.  The  AIS  should  implement  special  mechanisms  to  ensure  stores  ve  safe 
during  jettison  unless  specifically  demanded  to  be  jettisoned  armed. 

8.2.6.2  Fuzino  Times  Computatjon 

ISSUE:  What  AIS  performance  should  be  specified  for  the  fuzing  times? 

GUIDANCE:  The  AIS  should  provide  the  following  fuzing  times  performance. 

a  Provision  of  default  values  for  store  fuzing  times.  These  default  values  wW  be 
specific  to  aircraft/store  combination  and  should  be  defined  during  development. 

b.  Provision  for  receipt  of  fuzing  distance  data  from  the  aircraft.  Specifically  the 
following  should  be  received: 

•  Minimum  safe  separation 

•  Aircraft  height  (at  release) 

•  Weapon  release  dynamics  (ejection  velocity,  rate  of  fall,  drag  etc) 

•  Aircraft  velocity  (at  release) 

•  Function  height/depth 

c.  Recalculation  of  fuzing  times  from  the  above  data  at  a  minimum  of  lOHz  during 
approach  and  release. 

d  Transfer  of  fuzing  data  to  stores  and  verification  of  correct  rece^Jt.  Fuzing  data 
should  only  be  updated  when  a  meaningful  change  in  value  is  detected  to  reduce  probability  of 
corrupting  'safe'  fuzing  times. 

8.2.7  SiQffl  RBteaSfl 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Store  Separation? 

GUIDANCE:  The  AIS  functions  as  determined  in  paragraph  7.4.7  are  listed  below.  They  are  aH 
implemented  in  the  AIS  only  if  dso  implementing  the  SMS  function.  As  such  they  are  not  core 
AIS  functions  and  only  brief  guidance  is  given. 

Suspension  Equipment  Management  Weapon  Bay  Management 

Separation  Ma^ement  Serration  Timing 

Separation  Sequettoe  Determination  Hang  up  Detection 

Balance  Management  Engine  Control  Assistance 
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8.2.7.1 


Susoensbn  and  Release  Eaupment  Manaoemflnt 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Suspension  and  Release  Equipment 
Management? 

GUIDANCE:  The  AIS  should  provide  signals  for  the  control  and  monitor  of  S&RE.  The  control  and 
monitor  signals  for  a  typical  weapon  station  are  shown  in  table  8.9. 

TABLE  8.9  Typical  AIS  •  S  &  RE  Signals 


Signal  Name 

IN/OUT 

Signal  Form 

EJECT/FIRE  PRIMARY 

our 

28  Volt/ 10  Ampi/Pulsed 

EJFCT/FIRE  SECONDARY 

OUT 

28  Volt/10  Amp/Pulsed 

RELEASE/FIRE  PRIMARY 

our 

28  Volt/ 10  Amp/Pulsed 

ARMING  1  (Nose) 

our 

28  VoU/IO  Amc/Pulsed  1  Amo  continuous 

ARMING  2  (Tain 

our 

28  Voh/IO  Amp/Pulsed  1  Amo  continuous 

our 

1 1  ■'IllitiTil  — 

GROUND  RETURNS  (2) 

our 

0  Volt/20  Amo  Pulsed 

WEAPON  LOADED 

IN 

2PDT  CONTINUITY  SENSE  (6  sionals) 

LOCKMONTTOR 

IN 

CONITNUITY  TO  GROUND  RETURN 

LAUNCHER  BIT 

IN 

CONTINUnY  TO  GROUND  RETURN 

IN  FLIGHT  LOCK 

our 

28  Volt/1  Amp  continuous  with  2PDT  monitor 

Additionally  the  AIS  should  provide  for  the  following  functions  of  the  signals  of  table  8*9: 

a  EJECT/FIRE  •  Used  to  separate  hook  mounted  stores  or  jettison  any  store  (rail  launch 
missiles  will  be  jettisoned  downwards  with  their  launchers).  The  AIS  should  provide  that  after 
one  mission  hour  the  probability  of  inadvertent  activation  of  one  of  these  signals  or  of  failure 
under  emergertcy  jettison  of  both  signals  is  extremely  low.  Typically  the  performance  should  be 
both  quantitative  (10*^)  and  qualitative  (no  single  fault  shall  cause). 

b.  RELEASE/FIRE  •  Used  to  separate  rail  launch  stores  (for  the  Modular  Rail  launcher 
this  removes  the  electrical  conrtections  from  the  aircraft  to  the  store).  This  signal  may  also  be 
used  for  non  MIL-STD-1760  stores  to  directly  initiate  motor  firing.  The  AIS  should  provide 
inadvertent  activation  performance  similar  to  Eject/Fire  and  should  possbiy  implement  two 
signals  for  assurance  of  release. 

c.  WEAPON  LOADED  -  Used  to  monitor  for  store  presence.  The  AIS  should  verify 
signals  in  correct  state  during  inventory  confirmation  and  monitor  for  changeover  of  switch 
contacts  during  eject  release  or  jettison. 

d  IN  FLIGHT  LOCK  -  This  is  generally  for  nuclear  weapon  use  (see  82.11).  This  sign^ 
is  sometimes  used  to  increase  safety  for  carrbr  based  aircraft. 

8.2.72  Weapon  Bav  Manaoement 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Weston  Bay  Management? 
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GUIDANCE:  There  are  no  generic  impiementations  of  weapon  bays  and  therefore  AIS  performance 
should  be  specified  individuatty  for  each  aircraft  Typical  AIS  functions  for  weapon  bays  might 
be: 


a  Provide  redundant  irmiation  signals  to  open  and  dose  bays.  This  must  be  achieved 
before  and  after  the  release. 

b.  Provide  initiation  signals  for  any  required  SARE  vertical  translation  and/or  rotation 

c.  Monitor  achievement  of  d)Ove  demands,  via  monitor  switches  and  provide  interlocks 
on  release  process 

8.2  7.3  Seoaraiion  Management 

ISSUE:  What  AIS  performance  should  be  specified  for  Separation  Manageme.rt? 

GUIDANCE:  The  AIS  shodti: 

a  Prevent  separation  when  not  demanded  by  critical  controls  -  after  1  mission  hour  the 
probability  of  inatNertent  separation  should  rtot  exceed  10*^  ar>d  prior  to  Master  Arm  or 
Jettison  no  single  AIS  failure  should  cause  inadvertent  separation. 

b.  Assure  separation  -  after  1  mission  hour  the  probability  of  failure  to  separate  any 
store  when  demanded  should  not  exceed  10*^  and  where  possible  no  single  AIS  failure  should 
prevent  separation  of  one  vreapon  of  any  store  type. 

c.  Provide  critical  state  control  to  stores  that  potentially  could  be  separated.  This 
should  also  indude  presetting  of  reversible  states  to  stores  whose  separation  will  only  be 
required  should  separation  of  any  store  fail. 

d.  Provide  for  'dead  facing*  of  power  at  the  ASI  of  separated  stores. 

a  Provide  for  tolerance  of  *no  responses”  to  data  bus  commands  to  stores  that  have  just 
been  separated. 

f.  Prevent  interpretable  radiation  of  sensitive  data  from  ASI  data  stubs  to  areas  outside 
the  aircraft. 

g.  Reconfigure  analog  networks  to  provide  maximum  connection  paths  to  stores  1^ 
deleting  arnf  reusing  network  circuitry  for  stores  separated. 

h.  Monitor  interlock  signals  for  determination  of  'store  gone/separated.* 

i.  Provide  for  aerodynamic  and  pmb^ity  of  success  analysis  k>  ktterfock  the 
separation  process. 

8.2  7.4  Separation  Timino 

ISSUE:  What  AIS  performance  should  be  specified  for  Separation  T^r>g? 

GUIDANCE:  The  AIS  should  provide  tor  rapid  and  accurately  timed  stwa  separ^tortt.  If  store 
internal  delays  and  station  to  station  minimum  spadngs  are  ignored,  the  AIS  should  provide  tor 
the  foNowtog  performance: 
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a  Separation  timings  acxiurate  to  3  ms  calculated  from  spacing  and  aircraft  dynamic  data 

b.  Separation  intervals  as  short  as  30  ms  with  up  to  two  stores  separated  per  interval 

c.  Minimum  safe  intervais  for  storas 

r>  Separation  spacings  from  10  to  1000  meters 

e.  Salvo  separatton  with  sequenced  separation  of  selected  stores  at  maximum  10  ms 
interval  with  no  haitg  up  monitoring 

8.2.7.5  Separation  Sequence  Determ.natio.-i 

ISSUE:  What  AIS  perfomiance  should  be  specified  for  the  Separation  Sequence? 

GUIDANCE:  As  defined  in  8.2.5. l  specific  separation  sequences  may  vary  with  aircraft,  store  or 
mission.  The  AIS  should  determine  separation  sequences  as  the  selection  sequences  but  should 
addi'ionally  provide  for  dynamic  changes  of  sequence  should  stores  fail  to  seoarate  or  lose  target 
acquisition. 

8.2.7.6  Hang  up  Detection 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Hang  up  Detection? 

GUIDANCE:  As  discussed  in  8.2. 7.1  and  8.2  7.3,  the  AIS  shoulu  monitor  the  Weapon  oaded 
signals  and  MIL-STD-1760  inierlocK  signals  to  determine  that  a  store  has  been  successfully 
separated.  Failure  of  any  two  signals  to  change  statd  within  25  ms  of  initiating  ejection  should 
be  interpreted  as  a  hung  store.  If  store  does  not  hang  up  then  failure  of  all  four  signals  to  change 
over  within  SO  rns  should  be  interpreted  as  a  mission  tolerable  failure.  Should  a  store  fail  to 
release  within  the  required  time  it  should  be  declared  "hung."  Hung  stores  should  be  set  safe  as 
specified  in  8.2  2.2  table  8-2.  Hang  up  Jelection  may  be  suspended  during  salvo  releases  where 
mission  requirements  dictate  release  at  a  faster  rate  than  the  response  times  of  the  S&rtE  weapon 
loaded  ir'dicating  switches.  Stores  may  also  be  set  hung  during  release  if  any  of  the  following  are 
detected,  although  it  is  preferable  that  a  'store  degraded'  state  be  reported: 

Failure  to  achieve  demanded  critical  states  Failure  of  MIL  STD'1553  communication 

Store  unsafe  condition  reported  Store  'fatal*  'ailure  reported 

8.2.7  7  EJancfl  Management 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Balance  Management? 

r^UIDANCE:  The  /.IS  should  determine  and  modify  separation  sequences  to  preserve  the  aircraft 
balance  within  the  limits  oefiowd  as  follows.  For  aircraft  of  wingspan  W  and  length  L; 

a  Maximum  Lateral  Imbalar'ce  Moment  -  200  W  Kg  meters 

b.  Maximum  lorgiiudinal  Imbalance  Moment  -  200  L  Kg  meters 

Note  that  who:  8  stores  are  moufitod  on  wings  that  can  be  sw^pt,  then  the  wing  sweep  angle  will 
affect  these  calculations. 

t.tample  •  For  an  aircraft  of  wingspan  13  meters  (43  feel)  the  imbalance  should  be  limited  to  a 
Mk  83  bomb  at  a  pylen/station  5.73  meters  (18  1/2  feet)  from  the  aircraft  certtedlne. 
Aiiernafivel/  a  Mk  84  .bomb  2.87  meters  (9.3  feet)  from  centerline. 
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8.2.7.8  Engine  Control  Assistance 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Engine  Control  Assistance? 

GUIDANCE: 

a  When  demanding  separation  of  rail  launched  stores,  rockets  or  guns  the  AIS  should 
provide  discrete  advisory  data  lo  the  aircraft  to  indicate  that  engine  performance  may  be 
disturbed.  The  data  format  will  be  specific  to  aircraft  and  should  indicate  whether  separation  is 
from  port  or  starboard.  The  data  should  be  present  for  a  minimum  of  20  ms  before  and  100  ms 
after  each  release. 

b.  When  demanding  separation  of  eject  launched  stores  with  internal  rocket  motors,  the 
AIS  should  compute  and  transfer  Motor  Fire  Delay  data  (MIL-STD-1760A  data  entity 
B40.3.1.21)  to  Stores  capable  of  actirig  upon  the  data.  Default  times  should  be  1600  ms 
(ensures  13  meters/50  feet  separation  with  gravity  drop). 

8.2.8  Store  Jettison 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Store  Jettison? 

GUIDANCE:  The  AIS  functions  as  determined  in  paragraph  7.4.8  are  listed  below.  They  are  all 
implemented  in  the  AIS  only  if  also  implementing  the  SMS  function.  As  such  they  are  not  core 
AIS  functions  and  only  brief  guidance  is  given. 

■  Selective  Jettison  Management 

•  Emergency  Jettison  Management 

•  Store  Safe  Verification 

8.2.8. 1  Selective  Jettison  Management 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Selective  Jettison  Management? 
GUIDANCE:  The  AIS  should  provide  the  following: 
a  S  &  RE  Management  as  defined  in  8.2.7. 1 

b.  Weapon  Bay  Management  as  defined  in  8  2.7.2 

c.  A  minimum  of  four  selective  jettison  modes: 

-  Selective  Jettison  Package:  A  preselected  set  of  defined  stores  determined  by 
crew  action.  These  may  be  selected  for  armed  or  safe  jettison. 

-  Post  Release  Jettison:  Automatic  compilation  of  a  crew  Initiated  selective 
jettison  package  to  jettison  all  stores  'hung*  during  release  (refer  to  8.2.7.6). 

-  Combat  Jettison:  Automatic  compilation  of  a  crew  initiated  selective 

jettison  package  to  remove  all  stores  (including  carriage  stores)  not  essential  to  air-air  combat. 

-  Station  Jettison:  Ability  to  individually  jettison  all  stores  from  selected 
stations.  This  may  be  safe  or  unsafe. 
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d  Selective  Jettison  should  be  implemented  via  a  sequenced  pattern  of  store  separations. 
The  default  sequence  should  be  of  the  same  basic  form  as  the  release  sequence  defined  in  8.2.7.5 
except  that  store  types  may  be  muiiiple.  The  timing  should  be  the  minimum  safe  duration 
(default  time  of  80  ms)  and  the  balance  requirements  of  8.2.7.7  should  be  met.  Where  possible 
the  sequence  should  be  optimized  to  remove  the  maximum  weight  as  fast  as  possible.  This  will 
modify  the  sequence  where  stores  have  either  long  jettison  execution  or  minimum  safe  spacing 
timings. 

e.  Jettison  prevention,  assurance,  critical  state  control,  power  deadfacing,  ’no 
response’  tolerance  and  sensitive  data  protection  as  specified  for  release  in  8.2.7.3 

8.2.8.2  Emergency  Jettison  Management 

ISSUE;  What  AIS  performance  should  oe  specified  for  the  Emergency  Jettison  (EJ)  Management? 

GUIDANCE:  The  AIS  should  provide  an  Emergency  Jettison  function.  This  should  be  identical  to 
Selective  Jettison  except  as  that  it  should  be  initiated  by  a  separate  critical  cockpit  switcn,  have 
no  operator  definable  packages,  and  have  a  higher  assurance.  After  1  mission  hour  the 
probability  of  being  unable  to  emergency  jettison  any  store  when  intended  should  not  exceed 
10  No  single  AIS  failure  should  prevent  the  emergency  jettison  of  any  store  when  intended. 
All  stores  will  be  jettisoned  §afe  when  EJ  is  demanded  except  for; 

-  Nuclear  Weapons 

•  Stores  from  stations  determined  by  aircraft  design  as  not  essential  for  EJ 

•  Stores  only  jettisoned  by  forward  firing 

8.2  8.3  Store  Safe  Verification 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Store  Safe  Verification? 

GUIDANCE:  The  AIS  should  provide  the  following  for  jettisoned  stores: 

a  Data  Bus  ard  S  &  RE  management  to  remove  any  arming  and  fuzing  if  jettison  is  not 
demanded  as  armed.  Where  stores  can  be  monitored  ana  cannot  be  set  safe  then  selective  jettison 
of  these  stores  should  be  inhibited  and  the  crew  notified  so  that  they  can  consider  alternative 
action. 


b.  Where  security  sensitive  stores  are  selected  for  unarmed  selective  jettison,  data  bus 
commands  to  demand,  and  monitor  for  achievement,  erasure  of  all  sensitive  data.  Where  stores 
can  be  monitored  and  cannot  be  set  ’clear*  the  selective  jettison  of  these  stores  should  be 
inhibited  and  the  crew  notified  so  that  they  can  consider  alternative  action. 

8.2.9  Inventory 

ISSUE;  What  AIS  performance  should  be  specified  for  the  Inventory? 

GUIDANCE:  The  AIS  should  provide  the  following  Inventory  functions; 

a  Inventory  load 

b.  Inventory  confirmation 

c.  Inventory  update 
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8.2.9.1  Inventory  Load 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Inventory  Load? 

GUIDANCE:  The  AIS  should  provide  for  an  aircraft  input  determining  inventory.  This  should  be 
by  receipt  of  a  chedtsummed  data  block  from  avionics  data  bus(es)  but  may  be  by  use  of  ioadout 
panels.  The  minimum  data  provkJod  should  include:  Store  types  at  specific  locations  and  Gun 
Rounds  (if  relevant). 

8.2.9.2  Inventory  Confirmation 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Inventory  Confirmation? 

* 

GUIDANCE:  The  AIS  should  provide  for  confirmation  of  inventory  Ioadout  by  checking  at  mission 
start  that: 

a  S  &  RE  weapon  loaded  data  matches  defined  inventory  bad 

b.  MIL-STO-1760  interlock  data  matches  inventory  bad 

c.  MIL-STO-1760  store  type  data  matches  inventory  bad  at  relevant  statbns 
d  Any  available  existing  store  data  matches  inventory  load  at  relevant  statbns 

Any  errors  shoub  be  immediately  notified  to  the  aircrew  via  the  avbnics  data  bus.  Statbns 
where  checks  fail  should  be  indicated  as  unsafe  stores.  The  aircrew  should  be  able  to  override 
these  unsafe  determinatbns  if  required.  This  override  should  be  demanded  via  specific  data 
commands  from  the  avbnics  bus. 

8.2.9.3  lnv.eniQ.rY.  .Updaie 

ISSUE:  What  mIS  performance  should  be  specified  for  the  Inventory  Update? 

GUIDANCE:  The  AIS  should  provbe  the  following: 

a  Secure  data  base  of  inventory.  This  should  survive  short  term  be  availabb  to  the 
avionics  via  data  bus  commands  and  should  minimally  contain  for  each  store  statbn  the  foibwing 
data:  Store  type,  Store  Loaded  or  Released  or  Jettisoned,  and  Store  Critical  State  (Safe.  Selected, 
Armed,  Firing  or  Hung). 

b.  Update  of  inventory  data  base  during  the  following  processes:  Store  Selectbn.  Store 
Release,  and  Store  Jettison. 

8.2.10  Crew  Interface 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Crew  Interfaces? 

GUIDANCE:  The  AIS  functbns  br  crew  interfaces  are  limited  in  paragraoh  7.4.10  b  the  critical 
controls.  The  following  dedicated  critical  controls  should  be  provbed. 

a  Air-Air  Launch/Fire  is  a  dedbated  momentary  actbn  switch  br  the  pibi  (and  also 
navigator  if  relevant). 

b.  Air-Gmund  Release  is  a  dedicated  momentary  switch  for  the  pibt  (ano  also  navigator 
it  relevant). 
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c.  DAS  Release  is  a  dedicated  latching  switch  for  the  pilot  (arxi  navigator)  allowing  long 
term  consent  for  release  of  chaff,  flares  and  missiles  for  self  defense.  The  AIS  should 
automaticalty  reset  this  control  to  safe  if  Master  Arm  is  not  demanded. 

d  Master  Arm  is  a  dedicated  latching  switch  foi  the  pilot  (and  also  navigator  if 
relevant)  used  as  consent  for  release  preparation  and  weapon  arming  on  all  aircraft  and  jettison 
on  some  aircraft. 

e.  Selective  Jettison  is  a  dedicated  momentary  action  switch  for  the  pilot  (and  also 
navigator  if  relevant). 

f.  Emergency  Jettison  is  a  dedicated  momentary  action  switch  for  the  pilot  (and  also 
navigator  if  relevant). 

g.  Gear  up  and  locked  are  dedicated  switches  sensing  that  the  aircraft  is  airtwrne  and 
separation  will  not  be  obstructed  by  the  undercarriage. 

h.  Ground  Test  Override  is  a  dedicated  latching  switch  witn  a  highly  visible  warning, 
such  as  a  *flag,‘  to  allow  override  of  gear  up  and  locked  switches  when  testing  AIS  or  stores  on 
the  ground. 

8.2.11  Nuclear  Control 

iSSUE:  What  AIS  performar>ce  should  be  specified  for  fJuclear  Control? 

GUIDANCE:  For  nuclear  certified  aircraft  the  AIS  should  provide  the  following  functions  at  the 
relevant  stations; 

a  S  &  RE  Management 
h.  PAL  code  transfer 

c.  Controls 

d.  Displays 

e.  Store  Interface 

Specific  g  jidance  for  these  is  containoJ  in  government  documents  such  as  AFR  122-10  and 
MIL-HD8K-255.  Paragraphs  8.2.11.1  -  8.2.11.5  below  state  briefly  the  relevant 
requirements. 

8.2.11.1  Nuclear  S  &  RE  Manarement 

ISSUE:  What  AIS  performance  ’»hould  be  spedfled  for  the  Nuclear  S  &  RE  Management? 

GUIDANCE:  S  &  RE  for  nuclear  weapons  differ  in  use/implementation  from  S  4  RE  for  other 
stores  in  that  tliey  implement  an  in  flight  reversible  lock.  This,  when  unlocked,  allows  the 
weapon  to  be  separated  by  the  conventional  Eject  Signals.  When  in  the  locked  state,  the  Eject 
signals  are  isolated  from  the  cartridges  and  the  rack  is  mechanically  prevented  from  releasing 
the  weapon  even  i*  both  cartridges  should  fire.  The  AIS  should  make  tho  following  provisions: 

Isolate  all  power  from  S  &  RE  until  s>3rl  of  separation  preparatk'n?. 

No  single  AIS  failure  should  result  in  separation  or  should  p.avent  relocking  of  the  S 


a 

b. 

&RE. 
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c.  Control  of  Eject  and  In  Flight  Lock  signals  should  be  by  two  independent  mechanisms 
with  physical  and  electrical  isolation  of  discrete  signals. 

d  The  AIS  should  not  initiate  separation  even  with  two  ‘out  of  sequence*  operator 

errors. 

e .  The  AIS  shall  prevent  jettison  of  any  nuclear  weapon  in  an  unsafe  conation. 

f.  The  probability  of  unintentional  release  should  not  exceed  1  in  10^/weapon  station 
design  lifetime,  1  in  10^  abnormal  environment  exposure  when  locked,  and  1  in  10^  unlocking 
evenis. 

8.2.11.2  PAL  Code  Transfer 

ISSUE:  What  .MS  performance  should  be  spectfied  for  the  PAL  Code  Management? 

GUIDANCE:  Permissive  Active  Link  (PAL)  codes  are  used  as  an  authoraation  function  which  can 
interrupt  the  pre-arming  functions  of  the  store.  The  AIS  should  provide  for  crew  entry  of  PAL 
codes  for  each  weapon  carried.  Each  PAL  code  is  typically  a  6  digit  code.  The  AIS  must  ensure 
that  PAL  code  data  is  not  retained  in  the  AIS. 

8.2.11.3  Nuclear  Controls 

ISSUE:  What  AIS  performance  should  be  spectfied  for  the  Nuclear  Controls? 

GUIDANCE:  The  AIS  should  provide  the  following  controls: 

a  A  wire  guarded  nuclear  release  consent  swiich.  Where  there  are  two  or  more  airaew 
this  shall  be  at  each  of  two  crew  stations  such  that  a  single  crew  member  cannot  operate  both 
switches  with  effect. 

b.  A  wire  guarded  nuclear  arming  consent  switch.  Where  there  are  two  or  more  aircrew 
this  shall  be  at  each  of  two  crew  stations  such  that  a  single  crew  member  cannot  operate  both 
switches  with  effect. 

c.  Numeric  entry  switches  for  operator  input  of  unique  data  codes  for  prearniing  and 
other  functions. 

8.2.11.4  Nuclear  Displays 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Nuclear  Displays? 

GUIDANCE:  The  AIS  should  provide  the  following  display  information:  indication  of 
locked/unlocked  status  of  each  S  &  RE.  indication  of  ability  to  determine  pre-arm  status,  and 
indication  of  each  stores  pre-arm  status. 

8.2.11.5  Nuclear  Store  Interfaces 

ISSUE:  What  AIS  performance  should  be  ^>ecified  for  the  Nuclear  Store  Interfaces? 

GUIDANCE:  The  AIS  should  provide  at  relevant  stations  a  MIL-STD-1760  oon^iant  interface. 
For  non  MIL-STD-1760  Stores  compliant  System  1  interfaces  should  be  provid^.  These 
interfaces  should  be  managed  to  provide: 
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a  Maximum  probability  of  inadvertent  pre-arming  should  be  less  than  1  in  10^^/ 
weapon  system  lifetime. 

b.  Maximum  probability  of  inadvertent  authorization  should  be  less  than  1  in 
10^/year/weapon  system. 

c.  Maximum  probability  of  unintentional  transmission  of  'intent”  command  should  be 
less  than  t  in  10^/year. 

8.3  AIS  Gfloftrai  Performance  This  paragraph  contains  subparagraphs  8.3.1  through  8.3.6. 
These  provide  performance  guidance  for  the  following  subjects: 

a  Expansion  Provision 

b.  Reliability 

c.  Maintainability 
d  Volume/Mass 

e.  Environmental  Performance 

f.  Miscellaneous  Requirements 

8.3.1  Expansion  Provision 

ISSUE:  What  AIS  performance  should  be  specified  for  Expansion  Provisions? 

GUIDANCE:  Expansion  provisions  for  the  AIS  should  be  limited  to  provision  of  extra  store 
stations  and  extra  functional  performance  at  current  interfaces.  Because  all  new  stores  should 
have  MlL  STO-1760  interfaces  it  is  unlikely  that  additional  interface  types  will  be  required. 
The  following  initial  expansion  provisions  should  be  specified  for  the  AIS  at  system,  equipment 
and  module  level. 

a  System 

-  50%  of  installed  processing  capacity  to  be  unused 

•  50%  of  installed  program  and  data  memory  to  be  unused 

-  50%  of  data  bus  capacity  to  be  unused 

-  25%  of  installed  power  wiring  and  connector  pin  provision  to  be  unused 

•  25%  of  installed  high  bandwidth  wiring  and  connector  pin  provision  to  be  unused 

-  25%  of  installed  armament  rtetwork  discrete  wiring  and  connector  pin  provision  to  be  unused 

•  10%  of  all  other  installed  connector  pin  provisions  to  be  unused 

b.  Equipment 

•  20%  of  installed  module  space  allocation  to  be  unused  in  central  equipments 

-  50%  of  installed  internal  data  bus  capacity  to  be  unused 

-  20%  of  specified  maximum  power  consumption  to  be  unused  in  central  equipments 

•  predicted  estimates  of  reliability  and  environmental  tolerance  to  assume  20%  increase 
in  internal  power  dissipation 

c.  Module 

-  All  program  data  and  code  to  be  reprogrammable 

8.3.2  Reliability 

ISSUE:  What  AIS  performance  should  be  specified  for  Reliability? 
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GUIDANCE:  The  AIS  Should  provide  the  following  reliability  for  these  parameters: 

a  MTBD  (Mean  Time  Between  Defects) 

b.  MTBF  (Mean  Time  Between  Failures) 

c.  MTBCF  (Mean  Time  Between  Criticai  Failures) 
d  Damage  Tolerance 

8.3.2.1  MTBD  A  defect  is  defined  as  any  component  failure,  or  Built  in  Test  failure  report, 
regardless  of  whether  or  not  operational  performance  is  impaired.  The  MTBD  for  the  AIS  should 
not  be  less  than  250  hours. 

8.3  2.2  MTBF  A  failure  is  defined  as  an  inability  to  execute  or  potentially  execute  a  function. 
Failures  for  the  AIS  exclude  failures  in  redundant  inputs,  outputs  or  processing.  The  MTBF  for 
the  AIS  should  not  be  less  than  1000  hours.  Consideration  should  be  given  to  further  specifying 
that  the  probability  of  any  failure  being  present  should  not  exceed  10*^  when  measured  one 
hour  into  a  mission  started  100  hours  after  the  last  100%  system  test. 

8.3.2.3  MTBCF  A  critical  failure  is  defined  for  the  AIS  as  a  failure  that  would  directly  endanger 
life,  health  or  safety  of  flight.  The  MTBCF  for  the  AIS  should  not  be  less  than  1  X  iO^  hc'jrs. 
Consideration  should  be  given  to  further  specifying  that  the  probability  of  a  ciitica!  ii  ''  «re 
having  occurred  should  not  exceed  10'^  when  measured  one  hour  into  a  mission  start^v  «X) 
hours  after  the  last  100%  system  test. 

8.3.2.4  Damage  Tolerance  The  AIS  should  provide  for  tolerance  of  single  detects  to: 
a  Prevent  inadvertent  release/jettison 

b.  As  far  as  possible  provide  for  release  of  at  least  one  store  of  all  weapon  types 

c.  Provide  d^raded  release  capability  for  all  weapons  where  possible  (such  as  boresight 
firing  in  lieu  of  full  targeting  before  firing) 

8.3.3  Mainiainabilily 

ISSUE:  What  AIS  performance  should  be  specified  for  Maintainability? 

GUIDANCE:  The  AIS  Should  provide  specific  performance  for  these  parameters: 

a  Built  in  Test  (BIT)  detection 

b.  BIT  isolation 

c.  BIT  execution 

d.  MTTT  Mean  Time  To  Test 

e.  MTTR  Mean  Time  To  Repair 

f.  Modularity 

8.3.3.1  BIT  detection  The  AIS  should  provide  BIT  such  that  at  least  95%  of  all  defects  arising 
are  detected.  This  should  be  specified  as  a  Mean  Time  Between  Undetected  Defects  which  shouid 
exceed  5000  hours.  Consideration  should  be  given  to  specifying  a  Mean  Time  Between  Undetected 
Critical  Defect  (component  failures,  or  BIT  failure  reports,  which  degrade  the  instantaneous 
MTBCF)  of  25,000  hours. 

8.3.3.2  BIT  isolaiion  The  AIS  shouid  be  capable  of  isolating  at  least  90%  of  al  defects  to  a 
flight  tine  replaceable  module.  This  again  shouid  be  specified  as  a  Mean  Time  Between  Defects 
NOT  Isolated  which  should  exceed  5000  hours. 
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8.3.3  3  BIT  execution  The  MS  should  provide  for  three  BIT  rrxxles.  These  should  be  continuous 
in  flight  BIT,  operator  demandable  interruptive  BIT  and  Power  up  BIT.  Full  defect  detection  and 
isolation  performance  should  be  achieved  following  executksn  of  Power  Up  BIT  and  in  flight 
continuous  BIT.  Interruptive  BIT  should  additionally  provide  for  initiation  of  store  BIT. 

8.3.3.4  MTTT  The  AIS  should  have  an  on-aircraft  MTTT  of  less  than  5  minutes  using  only  BIT 
facilities. 

8.3.3.5  MTTR  The  AIS  should  have  an  on-aircraft  MTTR  of  less  than  20  minutes.  This  should 
include  execution  of  BIT,  removal  and  replacement  of  faulty  item  and  retest. 

8.3.3.6  Modularity  The  AIS  should  maximize  the  use  of  comnx>n  modules  used  in  other  avionic 
systems.  This  should  be  achieved  by  specifying  such  specific  items  as  CFE  or  GFE.  For  necessary 
unique  to  AIS  units  and  modules  the  AIS  should  provide  that: 

Total  #  of  unioue  units  and  modules  exceeds  2.5 

Total  #  of  unique  unit  and  module  types 

This  effectively  requires  that  each  unique  design  is  used  an  average  of  2.5  times  in  each  AIS. 

8.3.4  Volume/Mass 

ISSUE:  What  volume/mass  limitations  should  be  specified  for  the  AIS? 

GUIDANCE:  Specific  guidar>ce  is  difficult  to  provide  for  AIS  volume  and  mass  because  of  two 
factors:  the  high  weight  of  necessary  AIS  power  wiring  relative  to  typical  equipment  weights, 
and  the  airframe  specific  nature  of  volume  and  space  constraints.  Typical  volume/mass  figures 
can  be  set  as: 

a  1.7  liters  (100  in^)  and  1.7Kg  {3.81b)  per  ASI  for  equipment  local  to  weapon 
stations. 

b.  12.4  liters  (750  in^)  and  12.4Kg  (27  lb)  for  AIS  central  equipments. 

8.3.5  Environmental  Requirements 

ISSUE:  What  environmental  tolerance  should  be  specified  for  the  AIS? 

GUIDANCE:  Environmental  performance  is  specific  to  aircraft  as  it  is  derived  from 
considerations  of  aircraft  structure  and  mission  roles.  For  new  implementations  the  required 
performance  has  become  marf^edly  more  stressing.  Environments  for  integrated  rack  located 
modules  should  be  as  defined  for  Pave  Pillar  (see  SPA  -90099001  A).  Typical  requirements  are 
listed  below  for  the  main  categories  of  environment. 

EMC  EMP 

T  emperature/Altitude  Vibration/Shock 

Contamination 

8.3.5.1  EMC 

ISSUE:  What  AIS  performance  should  be  specified  for  the  EMC? 
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GUIDANCE:  AIS  e<H<^Hnent  should  comply  with  MIL-STD'461  Class  Alb  requirements  with 
RS03  field  intensities  of  typically  100  Volts/meter  tor  internal  fuselage  mounted  equipments 
arKl  200  Voits/meter  for  equipments  in  external  pylons. 

8.3.5.2  EMP 

ISSUE:  What  AIS  performance  should  be  specified  tor  the  EMP? 

GUIDANCE:  It  is  extremely  difficult  to  specify  EMP  performance  tor  the  AIS  because  of  the 
difficulties  in  absolute  testing  and  of  the  secure  nature  of  specific  data.  It  is  better  therefore  to 
specify  specific  AIS  design  and  test  considerations  (AIS  design  is  considered  in  section  9).  In 
(totermining  test  requirements,  consideration  should  be  given  to  the  form  of  EMP.  This  is 
generally  a  rapid  rise  time  and  short  duration  field  of  strength  exceeding  10  KVolt/meter.  This 
is  shiek^  by  the  aircraft  structure,  but  stiii  can  produce  1  K  Volt  spaces  on  imshielded  AIS 
signal  lines.  A  typical  EMP  test  is.  therefore,  to  inject  onto  every  AIS  equipment  external  signal 
line  a  one  cycle  sinusoidal  pulse  of  amplitude  1000  Volts.  This  should  be  repeated  tor  several 
sinusoidal  frequertcies  (to  avoid  fortuitous  resonant  dissipation)  between  1  MHz  and  20  MHz. 
The  source  impedance  tor  the  pulse  should  be  typically  10  ohms. 

8.3.5.3  Temperature/Altitude 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Temperature/Altitude 

GUIDANCE:  AIS  equipment  should  generally  be  to  MIL-E-5400  Class  2.  Equipment  nxHjnted 
adjacent  to  weapon  stations  should  be  to  class  3. 

8.3.5.4  Vibration/Shock 

ISSUE:  What  AIS  performance  should  be  specified  for  Vibration  and  Shock? 

GUIDAhK^E:  AIS  equipcrrents  should  generally  be  in  accordance  with  MIL-E-5400  figure  2  curve 
IVa  (lOg)  sinusoidal  vtoration.  Random  vibration  performance  shculd  be  specified  individually 
for  each  aircraft. 

8.3.5.5  Coniaminatiflii 

ISSUE:  What  AIS  performance  should  be  specified  tor  Contamination? 

GUIDANCE:  The  AIS  should  minimally  provide  tolerance  of  contamination  as  specified  in 
MIL-E-540O. 


8.3.6  Miscflllaneous 

ISSUE:  What  AIS  performance  should  be  spedfied  for  the  Miscellaneous  parameters? 

GUIDANCE:  It  is  not  possible  to  meaningfully  dehne  specific  AIS  performance  for  factors  such  as 
Power  Diss^tion,  Power  Consumption  and  other  factors  because  of  the  specific  to  aircraft  and 
aircraft  location  of  the  real  requirements. 

8.4  Interfaces  As  defined  in  section  7  the  AIS  has  interfaces  with  the  aircraft,  the  crew  and  the 
stores.  Although  each  of  these  should  be  dearly  specified  for  the  AIS,  the  relevant  crew  and 
stores  interfaces  have  already  been  specified  in  paragraph  8.2.  This  section  considers  therefore 
only  the  aircraft  InterfKes. 
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ISSUE:  What  AIS  performance  should  be  specified  for  the  aircraft  interfaces. 

GUIDANCE:  The  AlS-to-aircraft  interfaces  will  consist  of  the  areas  listed  below  which  are 
discussed  in  paragraphs  8.4.1  through  8.4.6. 

Power  supplies  Digital  Interfaces 

Discrete  Interfaces  Analog  Interfaces 

Connectors 

8.4.1  Pgwei  Supplifis 

ISSUE:  What  AIS  performance  should  be  specified  for  the  aircraft  power  supplies? 

GUIDANCE:  The  AIS  should  receive  from  the  aircraft  the  following  power  supplies  defined  in 
terms  of  availability,  voltage,  current  fault  clearance  and  interruption  characteristics: 

a  Availability  •  28  Volts  primary  supply 

28  VoHs  secondary  supply 
115  Volts  3  phase  primary  supply 
1 15  Volts  3  phase  secondary  supply 

b.  Voltage  •  Voltages  should  be  as  defined  in  MIL*STD-704  for  generation  equipment 
with  maximum  voltage  drop  of  0.5  volts. 

c.  Current  •  The  following  continuous  currents  should  be  available:  28  Volts  (primary 
and  secondary)  with  100  Amps  per  supply;  115  Volts  (primary  and  secondary)  with  50  Amps 
per  phase. 

d  Fault  Clearance  •  The  supplies  should  have  active  fault  clearing  to  prevent  excessive 
overcurrents.  ?erformar»ce  should  be  as  Table  8*10  for  %  of  maximum  continuous  current. 


TABLE  8-10  Overload  Percentages 


Duration  of  Overcurrent 

Must  Supply 

Must  Isolate 

100  mS 

650% 

* 

1  second 

230% 

. 

10  seconds 

130% 

400% 

100  seconds 

100% 

250% 

e.  Interruption  -  The  AIS  shall  tolerate  interruption  of  any  or  all  supplies  for  200  uS 
with  no  subsequent  effect  on  AIS  function  (outputs  may  be  disabled  during  interruption).  The 
AIS  shall  retain  all  inventory  data  during  interruption  of  any  or  all  si4}plies  for  a  minimum  of  1 
second.  No  power  supply  intenuption  may  cause  any  unintended  release.  No  single  power 
supply  failure  shall  prevent  separation  of  stores  in  Emergency  Jettison. 

8.4.2  Digital  Interfaces 

ISSUE:  What  AIS  performartce  should  be  specified  for  the  Digital  Interfaces  with  the  aircraft? 
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GUIDANCE:  The  AIS  should  interlace  with  the  aircrah  (figital  data  systems  via  a  redundant 
interface  with  a  High  Speed  Data  Bus  (HSDB).  The  interface  should  minimally  support  the 
following  performance  location  to  the  AIS: 

a  Data  Rate  of  100  K  bit  in  any  one  second  (peak  rate  may  be  higher) 

b.  Data  Up^e  rates  to  25  Hz 

c.  Addressing  space  of  5100  16  bit  data  words.  These  may  be 'paged*  (MIL-STO-1 553 
supports  only  1920  unle^  “paging*  of  subaddresses  is  used) 

d  Unk^  addressing  of  AIS  for  up  to  two  AIS  redundant  HSDB  terminals 

8.4.3  Discreifl  Intertaces 

ISSUE:  What  A!S  performance  should  be  specified  for  the  Discrete  Interfaces  with  the  aircraft? 

GUIDANCE:  Provided  that  the  critical  controls  are  implemented  within  the  AIS  there  are 
required  discrete  interfaces  (Address  designation  for  the  HSDB  is  considered  as  part  of  the  digital 
interfaces).  Discrete  interfaces  should  be  provided  for  the  following  data: 

a  Engine  Disturbance  Port 

b.  Engirte  Disturbance  Starboard 

c.  Camera  Event  Marker  (to  enable  recording  of  events  during  store  separation) 

8.4.4  AnalQO.  Interlaces 

ISSUE:  What  AIS  performance  should  be  specified  for  the  Analog  Interfaces  with  the  aircraft? 

GUIDANCE:  The  AIS  should  provide  the  following  bidirectional  analog  interfaces  with  the 
aircraft: 

a  Two  redundant  50  ohm  1.6  GHz  (specified  as  MIL-STD-1760  type  B) 

b.  Two  50  ohm  20  MHz  (specified  as  MIL-STD-1760  type  A) 

c.  Two  75  ohm  20  MHz  (specified  as  MIL-STD-1760  type  A) 

d  Two  redundant  78  ohm  1  MHz  interfaces  (specified  as  6dB  cut  off  at  20  Hz  and  1  MHz) 

Note  this  can  also  be  used  to  transfer  MIL-STD-1760  LB  signals  and  should  be  compatible  with 
such  transfers. 

8.4.5  Connectors 

ISSUE:  How  shall  connectors  be  specified  for  the  AIS  -  aircraft  interfaces? 

GUIDANCE:  The  AIS  should  provide  connectors  for  the  interfaces  with  aircraft  systems  as 
follows: 

a  Where  possto'e  MIL-C-38999  connectors  should  be  used. 

b.  Redundant  signal  interfaces  should  be  implemented  in  separate  connectors. 

c.  Power  signals  should  be  provided  in  separate  connectors. 

d  Power  should  be  provided  by  means  of  multiple  pins  per  supply.  The  preferred 
number  is  two  per  supply  and  return  where  each  pin  is  capable  of  supporting  the  maximum 
current  load. 

Note  that  this  gwdartce  does  not  apply  to  .4SI  connectors  which  are  defined  in  MIL-STD-1760. 
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9.  SYSTEM  DESIGN  ISSUES  AND  GUIDANCE 


This  section  descrft)es  those  issues  relevant  to  the  AIS  system  design  activity.  The  foliowing 
subparagraphs  are  included: 


Overview  of  the  system  design  process  9. 1 

AIS  functional  partitioning  9.2 

AIS  internal  interfaces  9.3 

System  design  documen^tion  9 . 4 

An  exarr^  system  included  to  show  the  impact  of  the  above  guidance  9 . 5 


9.1  Overview  of  the  System  Design  Process  The  AIS  system  designer's  role  is  to  design  a 
system  of  interacting  subfunctions  that  together  satisfy  the  AIS  requirements,  as  defined 
by  the  Concept  Definition  phase,  (sections  7  and  8).  The  essence  of  system  design  is  the 
concept  of  functional  partitioning.  As  shown  in  Figure  9.1.  the  designer  breaks  down  a 
high  level  complex  function  into  a  number  of  lower  level  and  individually  less  complex 
subfunctions  then  alocates  these  subfunctions  to  physical  elements,  such  as  LRUs,  or 
modules  in  an  integrated  rack.  To  achieve  this  the  designer  must  complete  the  following: 

a  Define  Subfunctional  partitions 

b.  Define  Internal  interfaces 

c.  Generate  functional  descriptions  of  elements 

d  Define  System  mechanisms  used  to  implement  a  ‘high  level'  function 

9.2  AIS  Functional  Partitjonino  The  following  functional  partitioning  issues  are  considered 
here: 

a  Partitioning  viewpoints 

b.  Partitioning  of  External  functions 

c.  Partitioning  of  Internal  functions 

9.2.1  Partitioning  Viewpoints  When  partitioning  the  high  level  functions  into  subfunctions  and 
physical  elements  the  folowing  viewpoints  need  to  be  considered: 

a  Are  subfunctions  to  be  implemented  in  central  or  dislrtt)uted  equipments 

b.  Are  subfunctions  to  be  performed  by  existing  equipments  or  by  new  equipments 

c.  Are  suMunctions  to  be  performed  by  standard  elements  (such  as  standard  modules  for 
integrated  racks)  or  by  specialty  developed  dedicated  elements 

d  Are  subfunctions  to  be  performed  by  hardware  or  software 

These  viewpoints  will  be  used  when  considering  the  issues  to  be  discussed  but  the  relative 
priority  of  ^ese  viewpoints  for  a  particular  issue  will  vary.  The  major  high  level  fur>^ions  of 
the  AIS  can  be  divided  between  those  that  are  visbie  from  outside  the  AIS  ar^  those  that  are 
invisible,  that  Is  wholly  contained  within  the  AIS.  The  visbie  functions  are  referred  to  as 
external  functbns  and  the  invisbie  functions  are  referred  to  as  internal  functions. 

9.2.1 .1  External  Functions  The  external  functions  are  those  that  have  been  defined  in  the  AIS 
concept  definition  proc^.  These  functions  have  to  be  split  into  sibtunctbns  and  the 
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subfunctions  aNocated  to  elements  as  shown  in  Figure  9.1.  The  key  AIS  siAtfunctions  to  consider 
in  partitioning  the  external  functions  are: 


Power  Switching 
Analog  Network 
■  Data  Formatting 
Avionics  Interface  * 

Controls  * 

Reliability  * 

Safety  * 

9.2.1 .2  Internal  Functions  The  key  AIS  « 
are  listed  below  and  addressed  in  9.2.3. 


Safety  Critical  Switching 
AEIS  Bus  Control 
Existing  Store  Interfaces  * 

Displays  * 

Nut^ar  Control  * 

Success  * 

These  are  not  Core  AIS  functions 

lal  functions  to  consider  in  internal  partitioning 


-  Decision  Processirtg  BIT 

DataBase  Internal  Interface  Management 

Power  Regulation  Power  Distribution 

9.2.2  Partitioning  of  External  Functions  As  defined  earlier  an  ‘extemaP  function  is  a  definable 
function  of  the  AIS.  These  are  therefore  the  s^e  functions  as  considered  in  paragraphs  7  and  8. 
Sub  paragraphs  9.2.2.1  through  9.2.2.17  provide  partitioning  guidance  for  the  functions 
considered  in  8.2.1.  through  8.2.11  and  8.3.1  through  8.3.6. 


Hleh  L«v«l  Furtctlort  1  High  L*v*l  Function  2 


FIGURE  9.1  Functional  Partitioning 

9.2.2.1  Store  Interface  The  main  subfunctions  of  store  Interfaces,  identified  earlier  as  being 
located  in  the  AIS,  are  MIL-STD-1760  ASi  and  non-AElS  signals.  The  partitionktg  of  functiorts 
within  the  AiS  to  provide  the  non-AEiS  signals  is  very  deperKfenl  on  iridiyidual  aircraft 
r^irements  and  so  no  particular  guidance  is  offered  for  tiiis  area.  The  MIL>STD>1760  ASI 
signate  can  be  (Svided  into  eight  categories  which  are  fisted  betow.  The  following  par^aphs  give 
general  gitidance  of  how  these  signals  can  be  partitioned  within  the  AiS. 
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High  Bandwidth  signals 
Low  Bandwidth  signals 
Interlock 

-  Address  Discretes 


MUX  Buses 
Release  Consent 
Structure  Ground 
Power 


9.2.2.1.1  Hkih  Bandwidth  Signals 

ISSUE:  How  should  the  High  Bandwidth  network  function  be  partitioned  within  the  AIS? 

GUIDANCE:  The  switching  of  the  High  Bandwidth  signals  and  associated  networks  is  recommended 
to  be  provided  centrally  within  the  AIS.  In  a  retrofit  situation  existing  equipments  may  provide 
some  form  of  networking  but  this  would  probably  need  modifications  io  meet  all  the 
requirements  of  MIL-STO-1760. 

9.2.2.1.2  MUX  Buses 

iSSUE:  How  should  the  Mux  Bus  and  its  control  be  partitioned  within  the  AIS? 

GUIDANCE:  The  provision  of  the  bus  control  function  for  the  MIL-STD-1553  Mux  buses  is 
recommended  to  be  provided  centrally  within  the  AIS.  In  a  retrofit  situation  this  function  would 
probably  not  currently  exist  and  would  have  to  be  provided  by  new  equipment. 

9.2.2.1.3  Low  Bandwidth 

ISSUE:  How  should  the  Low  Bandwioih  network  function  be  partitioned  within  the  AIS? 

GUIDANCE:  It  is  recommended  that  this  be  treated  in  the  same  way  as  the  High  Bandwidth  signals 
and  therefore  this  function  should  be  provided  centrally  within  the  AIS.  For  retrofit  situations 
this  function  could  probably  be  incorporated  into  existing  equipments. 

9.2.2. 1.4  Release  Consent 

ISSUE:  How  should  the  Release  Consent  control  function  be  partitioned  within  the  AiS? 

GUIDANCE:  This  function  should  be  distributed  within  the  AIS  as  switching  of  this  safety  criticat 
signal  should  be  as  close  to  the  ASI  as  possible  to  reduce  the  effects  of  electromagnetic  pick  up  on 
the  wiring  to  the  ASI.  For  retrofit  situations  this  function  could  probably  be  incorporated  into 
existing  equipments. 

92.2.1.5  Interlock 

ISSUE:  How  should  the  interlock  monitoring  function  be  partitioned  within  the  AIS? 

GUIDANCE:  This  function  should  be  distributed  within  the  AIS  to  reduce  aircraft  wiring  by 
providing  monitors  within  the  local  store  station  equipments  and  transmitting  the  result  to 
process  control  equipment(s)  on  the  internal  AIS  Bus.  For  retrofit  situations  this  function  could 
probably  be  incorporated  into  existing  equipments. 


9.2.2.1.6  Structure  Groiind 

ISSUE;  How  should  the  Structure  Ground  function  be  partitioned  within  the  AIS? 


GUIDANCE:  This  function  should  be  distributed,  because  the  bonding  to  the  aircraft  structure 
should  be  made  as  close  to  the  ASI  as  possiNe.  Additional  bonding  points  would  probably  need  to 
be  provided  to  incorporate  this  in  a  retrofit  situation. 

9.2.2.1.7  Address  Discretes 

ISSUE:  How  should  the  Address  Determination  function  be  partitioned  within  the  AIS? 

GUIDANCE:  This  function  should  be  distributed  wittiin  the  AIS  to  reduce  aircraft  wiring  (see 
10.1.4.3).  In  a  retrofit  situation  this  function  would  require  new  equipment  to  provide  the 
necessary  shorting  links. 

9.2.2.1.8  Power 

ISSUE:  How  should  the  Powar  control  function  be  partitioned  within  the  AIS? 

GUIDANCE:  Wherever  possible  this  function  should  be  distributed  but  some  of  the  power 
switching  may  be  provided  centrally  if  necessary  (see  10.1.5).  In  a  retrofit  situation,  power 
switching  is  probably  already  provided  but  the  fault  isolation  elerrients  would  have  to  be  changed 
if  they  did  not  conform  to  the  requirements  of  MIL-STD-1780. 

9.2.2.2  Store  Critical  State 

ISSUE:  How  should  the  store  critical  state  function,  identified  in  7.4.2  and  8.2.2,  be  partitioned 
within  the  AIS? 

GUIDANCE:  Ail  of  the  three  AIS  subfunctions  of  the  store  critical  state  function  identified 
earlier,  namely  state  command,  state  monitor  and  power  supply  management  are  considered  as 
central  functions  within  the  AIS.  For  MIL-STD-1760A  stores  the  primary  method  of  critical 
Slate  control  is  via  the  Mux  bus  using  the  critical  control  and  authority  words.  The 
requirements  of  the  standard  necessitate  the  use  of  a  high  integrity  bus  controller,  which  in  a 
retrofit  situation  is  unlikely  to  be  available.  This  bus  controller  would  therefore  have  to  be 
provided  within  new  equipment. 

9.2.2.3  Data  to  Store 

ISSUE:  How  should  the  relevant  Data  to  Store  functions,  identified  in  7.4.3  and  8.2.3,  be 
partitioned  within  the  AIS? 

GUIDANCE:  The  three  AIS  subfunctions  of  the  Data  to  Store  function  identified  earlier,  that  is 
unique  to  store  formatting,  recomputation  to  store  axes,  and  interlace  with  store,  should  be 
performed  centrally  within  the  AIS.  The  standard  defines  the  interface  to  the  store  for  data 
transfer,  that  is  the  Mux  bus,  and  also  defines  the  data  formats  to  be  used  on  the  bus.  The  AIS 
would  require  processing  power  for  the  data  formatting  and  a  bus  controller  to  either  transmit 
or  control  the  transmission  of  the  data  to  the  store.  In  a  retrofit  situation  an  existing  processor 
may  be  able  to  perform  the  data  formatting  but  the  bus  controller  would  probably  not  exist  and 
so  would  have  to  be  added  as  new  equipment. 

9.2.2.4  Data  from  Store 

ISSUE:  How  should  the  relevant  Data  from  Store  functions,  Identified  In  7.4.4  and  8.2.4,  be 
partitioned  within  the  AIS? 
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GUIDANCE:  The  three  AIS  subfunctions  of  Data  from  Store  identified  earlier,  that  is  unique  to 
user  formatting,  recomputation  to  user  axes,  and  interface  with  avionics,  should  be  performed 
centrally  within  the  AIS.  The  standard  defines  the  interface  to  the  AIS  for  data  transfer,  that  is 
the  mux  bus,  and  also  defines  the  data  formats  to  be  used  on  the  bus.  The  AIS  would  require 
processing  power  to  reformat  the  store  data  for  use  by  the  avionics  and  a  bus  controller  to  either 
receive  or  control  the  reception  of  the  data  from  the  store.  In  a  retrofit  situation  an  existing 
processor  tray  be  able  to  perform  the  data  formatting  but  the  bus  controller  would  probably  not 
exist  and  so  would  have  to  be  added  as  new  equipment. 

9.2.2.5  Store  Selection 

ISSUE:  Hew  should  the  relevant  Store  Selection  functions,  identified  in  7.4.5  and  8.2.5,  be 
partitioned  within  the  AIS? 

GUIDANCE:  The  three  AIS  subfunctions  of  Store  Selection  identified  earlier,  that  is  station 
determination,  store  initialization  management,  and  weapon  package  retention,  are  all  dependent 
on  particular  aircraft  and  store  implementations,  but  should  be  implemented  centrally.  This 
function  is  not  affected  by  MIL-STO-1760. 

9  2.2.6  Store  Fuzing 

ISSUE:  How  should  the  relevant  Store  Fuzing  functions,  identified  in  7.4.6  and  8.2.6,  be 
partitioned  within  the  AIS? 

GUIDANCE:  Both  the  AIS  subfunctions  of  Store  Fuzing  identified  earlier,  that  is  fuzing 
management  and  fuzing  times  computation,  are  dependent  on  particular  aircraft  and  store 
implementations  but  should  be  implemented  centrally.  This  function  is  not  affected  by 
MIL.STD-1760. 

9  2.2.7  Store  Release 

ISSUE:  How  should  the  relevant  Store  Release  functions,  identified  in  7.4.7  and  8.2.7,  be 
partitioned  within  the  AIS? 

GUIDANCE:  The  eight  AIS  subfunctions  of  Store  Release  identified  earlier,  that  is  Suspension 
Equipment  Management.  Weapon  Bay  Management,  Release  Management.  Release  Timing,  Release 
Sequence  Determination,  Balance  Management,  and  Engine  Control  Assistance,  are  all  dependent 
on  particular  aircraft  and  store  implementations,  but  should  be  implemented  centrally.  This 
function  is  not  affected  hy  MIL  STO-1760. 

9  2.2.8  Store  JelliSQn 

ISSUE:  How  should  the  relevant  Store  Jettison  functions,  identified  in  7.4.8  and  8.2.8,  be 
partitioned  within  the  AIS? 

GUIDANCE:  The  three  AIS  subfunctions  of  Store  Jettison  identified  earlier,  that  is  Selective 
Jettison  Management,  Emergency  Jettison  Management,  and  Store  Safe  Verification,  are  all 
dependent  on  particular  aircraft  and  store  implementations  but  should  be  implemented  centrally. 
This  function  is  not  affected  by  MIL  STD-1760. 
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9.2.2.9  Inventory 


ISSUE:  How  should  the  relevant  Inventory  functions,  identified  in  7.4.9  and  8.2.9,  be 
partitioned  within  the  AIS? 

GUIDANCE:  Both  AIS  subfunctions  of  Inventory  identified  earlier,  that  is  Inventory  Confirmation 
and  Inventory  Update  in  Mission,  should  be  implemented  centrally.  The  store  description  pages 
defined  in  MIL-STO-1760  could  be  used  during  Inventory  confirmalicn.  This  store 
identification  information  could  be  transferred  from  the  stores,  using  the  MIL-STD-1553 
stores  bus,  to  the  central  control  equipments  to  confirm  the  correct  store  is  present  at  each  ASI. 

9.2.2.10  Crew  Interface 

ISSUE:  How  should  the  relevant  Crew  Interface  functions,  identified  in  7.4.10  and  8.2.10.  be 
partitioned  within  the  AIS? 

GUIDANCE:  The  critical  controls  interface,  identified  earlier  as  the  only  AIS  subfunction  of  Crew 
Interface,  should  be  distributed.  The  actual  interfaces  included  are  dependent  on  the  particular 
aircraft  implementation,  but  they  form  a  key  part  of  the  safety  critical  control  function  of  the 
AIS.  The  monitoring  of  these  interfaces  should  be  performed  centrally.  This  function  is  not 
affected  by  MIL-STD-1760. 

9.2.2.1 1  Nuclear  Controls 

ISSUE:  How  should  the  relevant  Nuclear  Control  functions,  identified  in  7.4.11  and  8.2.11,  be 
partitioned  within  the  AIS? 

GUIDANCE:  The  three  AIS  subfunctions  of  Nuclear  Control  identified  e3r!ier,  that  is  S  &  RE 
Management,  Crew  Controls  and  Crew  Displays,  should  be  performed  centrally  within  the  AIS. 
Their  functions  will  be  dependent  on  particular  aircraft  implemertations  and  not  affected  by 
MIL-STD-1760.  Note  that  two  subaddresses.  19  and  27,  are  resen/ed  iti  MIL-STD-1760  for 
communications  with  Nuclear  Stores. 

9.2.2.12  Expansion  Provision  Three  issues  are  discussed  here:  Memory,  Processing,  and 
Interfaces. 

9.2.2.12.1  Memary 

ISSUE:  Where  should  memory  expansion  capabiliiies  be  provided  within  the  AIS? 

GUIDANCE:  Memory  expansion  for  the  AIS  needs  to  be  provided  centrally  within  the  units 
associated  with  system  control  and  management. 

9.2.2.12.2  Processing 

ISSUE:  Where  should  spare  processing  capacity  be  provided  within  the  AIS? 

GUIDANCE:  Spare  processing  capacity  needs  to  be  provided  centrally  for  the  AIS  within  the  units 
associated  with  system  control  and  management. 

9.2.2.12.3  Interfaces 

ISSUE:  Where  should  the  capability  for  additional  store  interfaces  be  provided  within  the  AIS? 
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GUIDANCE;  The  design  of  the  system  as  a  whole  should  accommodale  the  addition  of  extra 
MIL  STD-1760  Store  interfaces  with  minimal  hardware  or  software  changes.  This  could  be 
achieved  by  allowing  additional  ASIs  and  their  associated  Store  Station  Equipments  to  be  added 
with  minimum  effect  on  the  existing  equipments.  Consideration  should  be  given  to: 

a  Providing  spare  remote  terminal  addresses  on  the  stores  and/or  armaments  buses  to 
accommodate  additional  equipments  and  interfaces 

b.  Providing  expansion  capability  for  the  internal  AIS  discrete  and  power  interfaces  to 
accommodate  addhtonal  equipments 

c.  Providing  modular  software  which  can  easily  accommodate  the  addition  of  extra 
equipments  and  interfaces 

9.2.2.13  Reliability 

ISSUE:  How  should  the  reliability  of  the  system  be  partitioned  within  the  AIS? 

GUIDANCE:  The  reliability  figures  in  terms  of  MTBF,  MTBCF  and  MTBD  esn  be  apportioned 
between  the  different  units  within  the  system  to  give  budgets  for  the  individual  LRU  designers  to 
work  with.  An  example  of  this  partitioning  for  MTBF  and  MTBD  is  shown  in  Figure  9.2  for  a 
simple  eight  station  system  with  a  high  level  of  standby  redundant  circuitry. 


FIGURE  9.2  Typical  System  Reliability  Breakdown 
9.2.2.14  Maintainability 

ISSUE:  How  should  the  maintainability  requirements  of  the  system  be  partitioned  within  the 
AIS? 


187 


GUIDANCE;  The  main  partitioni‘\g  assoc'sted  with  maintainability  that  can  be  a^^hieved  is  for  the 
Built  in  Test  (BIT)  function.  The  cor.irol  of  the  BIT  function  should  be  located  in  the  central 
processing  and  control  equipment.  Dedicated  monitoring  circuitry  for  self  testing  should  be 
distributed  throughout  the  system  to  allow  the  central  processing  and  control  equipment  to  check 
that  demands  have  been  correctly  implemented  and  the  system  is  in  the  correct  state.  Any 
failures  identified  should  be  rearded  in  BIT  result  storage  facilities  within  the  failed  unit. 

9.2.2.15  Volume/Mass 

ISSUE;  tVhat  guidance  can  be  given  for  the  partitioning  of  volume  and  mass  within  the  AIS? 

GUID\NCE;  No  specirtc  guidance  is  offered  in  this  area  as  it  is  dependent  on  the  position  and  space 
aval'  ble  for  the  various  equipments  on  a  particular  aircraft. 

9.2.2.16  Environmental 

ISSUE;  What  guidance  can  be  given  for  the  effects  of  environment  on  the  partitioning  within  the 
AIS? 

GUIDANCE;  No  specific  guidance  is  given  here  as  this  has  previously  been  discussed  in  8.3.5. 

9.2.2.17  Miscellaneous 

9.2.2.17.1  Power  Dissipation 

ISSUE;  What  guidance  can  be  given  for  the  effects  of  power  dissipation  on  the  partitioning  within 
the  AIS? 

GUIDANCE;  No  specific  guidance  is  offered  in  this  area  as  the  power  dissipation  for  an  individual 
equipment  is  limited  by  its  position  and  the  environmental  conditions  of  a  particular  aircraft. 
The  potential  availability  of  blown  air  or  liquid  cooling  should  be  considered  to  enhance  the  MTBF 
figures.  However,  these  will  probably  not  be  available  outside  of  the  fuselage  section  of  the 
aircraft. 

9.2.2.17.2  Power  Consumption 

ISSUE;  What  guidance  can  be  given  for  the  effects  of  power  consumption  on  the  partitioning 
within  the  AIS? 

GUIDANCE:  Power  consumption  of  the  equipments  within  the  system  should  be  considered 
negligible  compared  with  the  possible  power  requirements  of  MIL-STD-1760  stores,  that  is  2 
KW  for  Primary  connector  and  6  KW  for  Auxiliary  Connector. 

9.2.3  Partitioning  of  Internal  Functions 

ISSUE;  How  should  the  AIS  system  designer  implement  internal  functions? 

GUIDANCE:  As  defined  earlier  an  internal  funchon  is  not  a  true  function  of  the  AIS  but  is  a 
clearly  identifiable  function  of  the  probable  AIS  design.  Internal  functions  considered  in  9.2.3.1 
through  9. 2.3.6  include  Decision  Processing,  BIT,  Data  Base,  Internal,  Interface  Management, 
Power  Regulation  and  Power  Distribution.  As  these  are  not  core  AIS  functions  only  brief 
guidance  is  gtvi:;n. 
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9.2.3. 1  Decision  PfQces£ing  Decision  processing  is  that  processing  which  changes  the  execution 
of  repetitive  processes.  As  an  example  target  data  may  be  computed  and  transferred  over  a  fixed 
path  at  a  rate  of  10  Hz.  There  may  be  a  number  o'  conditions  which  require  that  rate  to  be 
increased  to  20  Hz.  This  change  cannot  be  executed  unilaterally  by  the  target  data  computation 
and  a  decision  has  to  be  made  to  increase  the  rate.  It  is  such  decisions  that  are  effected  by 
decision  processing.  They  fomt  the  highest  levels  of  processing  in  the  AIS.  For  the  AIS  typical 
decision  processing  required  is  determination  of  store  states,  definition  of  data  paths,  and 
determination  of  S&RE  states.  The  input  data  to  these  functions  is  derived  from  many  dispersed 
sources  and  must  either  be  brought  together  at  one  central  point  or  communicated  to  equ^ment 
local  to  the  actions  required.  Clearly  the  latter  alternative  requires  more  data  transfers,  more 
processing  and  greater  merTK)ry  requirements.  For  these  reasons  decision  processing  should  be 
executed  centrally  by  AIS  software  elements. 

9.2.3. 2  BIX  This  furKtion  has  already  been  discussed  under  maintainability  in  paragraph 

9.2.2  14. 

9.2. 3.3  Data  Base  This  function  should  be  performed  centrally  as  it  supports  the  decision 
processing  function  which  is  recommended  as  a  centralized  function.  The  data  base  content  is 
discussed  in  paragraphs  8  and  1 1 . 

S.2.3A  Internal  Interface  Management  There  are  dearly  many  internal  interfaces  within  the 
AIS.  The  most  important  of  these  are  the  highest  level  internal  interfaces  that  communicate 
between  the  highest  level  system  components.  As  has  been  considered  earlier  in  paragraph 
9.2.2,  there  will  have  to  be  several  physically  separate  equipments  in  the  AIS  to  reduce  wiring 
weights  and  provide  safety  against  EMI  hazards.  The  internal  interfaces  considered  here  are 
therefore  the  communication  links  between  those  equipments.  The  management  should  be 
performed  centrally  within  the  AIS  as  a  distributed  internal  interface  management  would: 

a  Complicate  the  system 

b.  Make  it  more  difficult  to  predict  the  safety  and  reliability  of  the  system 

c.  Increase  system  cost  and  weight 
d  Degrade  performance 

9.2.3. 5  Power  Regulation  Power  regulation  (the  conversion  from  aircraft  supplies  to  power 
supplies  used  by  AIS  electronic  circuitry)  should  be  distributed  to  each  AIS  equipment  for 
several  reasons: 

a  It  avoids  an  excessive  power  dissipation  burden  appearing  in  any  one  equipment. 

b.  It  provides  for  greater  fault  tolerance. 

c.  It  provides  higher  EMC  performance  (both  susceptibility  and  emission). 

d  A  centralized  system  would  inevitably  still  require  local  regulation  of  part  regulated 
central  power  sources  (such  as  7  volts  locally  regulated  to  5  volts).  This  will  increase  the  total 
power  dissipation  and  equipment  cost  and  weight. 

9.2  3.6  Power  Distribution  This  function  should  be  performed  from  a  central  unit  to  allow  the 
central  decision  processing  function  to  more  easily  monitor  and  control  the  state  of  the  power 
within  the  whole  system.  This  will  also  simplify  the  aircraft  wiring  as  only  single  points  of 
connection  and  fault  clearance  will  be  needed  between  aircraft  power  and  the  AIS. 


9.3  A1S_  iDlernal  Interfaces 

ISSUE:  How  should  the  AIS  system  designer  address  specification  of  internal  interfaces? 


GUIDANCE:  The  AIS  system  designer  must  design  and  define  all  the  internal  interfaces  between 
elements.  These  interfaces  in  total  usually  exceed  the  external  interfaces.  As  defined  in  9.2.3.4 
the  most  important  internal  interfaces  are  those  between  the  separate  AIS  equipments.  The 
Guidance  provided  here  is  in  general  brief  because  the  internal  AIS  interfaces  are  dominated  by 
factors  other  than  MIL-STD-1760.  These  other  factors  include  the  existing  systems  retained  (if 
a  retrofit)  or  the  avionic  philosophies  such  as  Pave  Pillar,  if  a  new  program.  Issues  to  be 
considered  in  defining  interfaces  include: 

Connectors  and  Cabling  Power  Interfaces 

-  Digital  Interfaces  -  Discrete  Interfaces 

Analog  Signals 

9.3.1  Connectors  and  Cablirw 

ISSUE:  How  should  the  AIS  system  designer  specify  cables  and  connectors? 

GUIDANCE: 

9.3.1. 1  Analog  and  Mux  Bus  It  is  recommended  that,  whenever  possible,  separate  connectors  be 
used  for  the  folloviring  signals  to  tonsure  adequate  screening  of  these  signals  is  maintained: 

a  MUX  Bus  A 

b.  MUX  Bus  B 

c.  High  Bandwidth  1  and  associated  internal  netwoh' s 

d.  High  Bandwidth  2  and  associated  internal  networks 

e.  High  Bandwidth  3  and  associated  internal  networks 

f.  High  Bandwidth  4  and  associated  internal  networks 

g.  Low  Bandwidth 

Space  limitations  may  prevent  this  so  as  a  minimum  all  the  above  signals  should  have  separate 
Triaxial  or  Coaxial  contacts. 

9. 3. 1.2  Power  Wherever  possible  high  current  signals  and  low  current  signals  should  be 
routed  through  separate  connectors  to  reduce  conducted  interference  onto  signal  lines  from 
switching  of  high  currents  on  other  lines.  The  sizes  of  cable  and  connector  contacts  used  for 
routing  power  signals  should  be  the  largest  that  are  practice,  to  reduce  the  voltage  drops  through 
the  AIS.  As  MIL-STD-1760  requires  the  use  of  size  10  and  16  contacts,  these  will  be  the  default 
sizes  in  the  AIS  equipment  connectors.  If  excessive  voltage  drops  occur  within  the  AIS  wiring  it 
will  be  very  difficult  to  comply  with  the  power  interface  requirements  of  MIL-STD-1760. 
Wherever  possible  the  power  winng  should  be  routed  separately  and  pass  through  connectors 
which  do  not  carry  other  types  of  signals.  This  should  reduce  interference  on  other  signals 
caused  by  current  or  voltage  changes  on  the  power  tines. 

9.3.1 .3  Connector  Ranges  The  preterred  connector  type  is  MtL-C-38999  series  III. 
MIL-C-38999  connectors  are  required  {by  AFR-122-10)  for  most  connections  for  any  nuclear 
certified  AIS.  and  their  high  reliability  and  'chatter  proof*  performance  offer  system 
performance  benefits.  The  series  III  connectors  feature  a  'scoop  proof  threaded  lock  design 
which  provides  benefits  in  both  mating  and  security  of  connection,  as  well  as  providing  a  high 
level  of  protection  against  EMC. 

9.3.2  PQweL,imsl!aC9S 

ISSUE:  How  should  the  AIS  system  designer  specify  power  interfaces? 
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GUIDANCE:  The  external  power  interfaces  are  specified  in  paragraph  8.4.?  arnf  MIL-STD-1760. 
In  specifying  the  internal  power  interfaces  the  AIS  designer  needs  to  considc*  how  the  voltage 
drops  (from  the  aircraft  power  supplied  to  the  ASI)  will  be  partitioned  throughout  the  AIS.  Oice 
this  has  been  completed  the  system  designer  can  specify  for  each  AIS  equip.-nent  the  voltage, 
current,  fault  isolation  and  power  interrupt  characteristics. 

9.3.3  Digital  Interfaces 

ISSUE:  How  should  the  designer  specify  the  use  of  digital  transmission  in  the  AIS? 

GUIDANCE: 


^  Digital  transfer  standards  selection  it  is  recommended  that  a  MlL-STD-fSSd  dual 
redundant  data  bus  be  used  for  internal  AIS  digital  data  transfer.  The  AIS  is  already  committed  to 
provide  MIL-STD-15M  interfaces  to  the  ASI  and  so  it  would  simplify  the  design  of  the  AIS  if  the 
same  method  of  digital  data  transfer  is  used  internally.  Other  digital  transfer  standards  that  may 
be  relevant  are  the  Pl-Bus  (a  16  bit  parallel  bus  intended  for  communication  between  starrdard 
modules  in  int^rated  racks)  artd  the  High  Speed  Data  Bus  (a  standard  bus  still  in  definition 
which  will  provide  data  rates  and  capacities  of  at  least  an  order  of  magnitude  higher  than 
MIL-STD-1553).  These  standards  are  applicable  to  the  AIS  but  only  for  inter  module 
communication  and  interfacing  with  the  avionics  data  centers. 

S-3.3.2  ConSQlidatiQn  with  other  buses  It  is  recommended  that  the  same  bus  is  used  tor  both  the 
MIL-STD-1760  mux  bus  and  the  internal  AIS/SMS  bos.  A  single  dual  redundant  bus  should  be 
adequate  to  support  the  bus  traffic  requirements  of  the  stores  and  the  SMS  and  the  single  dual 
redundant  bus  would  reduce  the  aircraft  wiring  and  Bus  Control  requirements.  A  limiting  factor 
especially  on  larger  systems,  may  be  that  the  number  of  Remote  Terminal  addresses  required  ’ 
iriternally  to  the  SMS  and  for  all  the  store  stations  exceeds  the  number  of  addresses  available  on  a 
single  bus  (31).  Other  limiting  factors  to  consider  may  be  the  electrical  performance  of  the  bus 
and  the  data  capacity,  if  a  large  number  of  stores  are  to  be  simultaneously  targeted.  In  these 
cases  two  or  more  separate  dual  redundant  buses  may  be  provided.  Where  two  or  more  dual 
redundant  buses  are  implemented,  the  first  partitioning  of  these  buses  should  be  to  separate 
MIL-STD-1760  and  SMS  (including  existing  store  data)  transfers.  Should  further  partitioning 
be  required  to  three  or  more  dual  redundant  buses,  then  the  design  should  avoid  Vertical' 
partitioning  of  buses  (where  data  is  routed  through  levels  of  data  buses)  and  instead  inorporate 
two  or  more  AIS  Bus  Controllers  in  the  same  central  equipment.  These  should  be  allocaled  not  to 
port  and  starboard  ASI  but  instead  to  an  equal  mix  of  port/starboard  and  forward/rear  stations. 

^•3-3.3  gigtocQl  and  data  faimaift  n  is  recommended  that  where  applicable  the  internal  AIS  data 
formats  are  the  same  as  the  data  formats  defined  in  MIL-STD-1760.  Similarly  it  is 
recommended  that  where  applicable  the  AIS  uses  the  protocol  defined  in  MIL-STD-1760  This 
should  simplify  the  system  control  software  within  the  AIS  as  the  same  data  formats  and 
protocols  will  be  used  for  all  transfers  on  this  MIL-STD-1553  bus. 

9.3.4  Discrete  Interfaces 


ISSUE:  How  should  the  designer  specify  the  use  of  discrete  signals. 

GUIDANCE.  The  use  of  dtscrete  signals  is  recommended  to  provide  direct  safety  interlocks 
(safeguards)  on  critical  signals.  This  is  almost  essential  for  the  Release  Consent  signal  which  is 
be  Interlocked  wifi)  selection  of  Trigger/Weapon  Release.  It  is  recommoKted  that 
only  the  Master  ^  interlock  is  protected  by  discrete  signaling  within  the  AiS.  Othw  signate 
mtemal  to  the  AIS  may  need  similar  interlocks  such  as  the  safety  critical  signals  for  the  S  &  RE 
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Lastly  if  the  AIS  also  implements  the  SMS  function  there  will  have  to  be  a  high  htegrity 
implementation  of  Emerger>cy  Jettison.  This  will  require  that  even  with  the  MIL^STD-ITGO 
data  bus  failed,  then  stores  wiN  still  be  separated.  This  is  recommerxled  to  be  implemented  by 
use  of  backi^  discrete  signals.  In  summary,  to  each  remote  AIS  et^^ent  the  foNowing  si(^iks 
should  be  transferred  in  discrete  form;  Arming/Jettison  enable.  Release  A  ar>d  Release  B  enable, 
and  Emergerx^  Jettison  demarxJ. 

9.3.5.  Analoo  Sionais 

ISSUE:  How  should  the  designer  specify  the  use  of  AIS  internal  analog  signals? 

GUIDANCE:  MIL-STD-1760  requires  analog  networks  to  be  provided  for  the  following  signals: 

-  High  Bandwidth  1  (20Hz  to  1.6GHz)  -  High  Bandwidth  2  (20Hz  to  20MHz) 

-  High  Bandwidth  3  (20Hz  to  20MHz)  •  High  Bandwidth  4  (20Hz  to  20MHz) 

-  Low  Bandwidth  (DC  to  SOKHz) 

The  AIS.  in  providing  the  network  performance  required  by  paragraph  8.2.3S.1,  must 
implement  internal  analog  interfaces  as  these  signals  are  be^d  the  data  capacity  of  any  known 
digital  link.  As  discussed  in  paragraph  9.2.2.1 .1  these  signals  should  be  networked  centrally  arxl 
therefore  the  AIS  Interfaces  should  have  essentially  the  same  signal  specifications  as  in  MIL- 
STD-1760A. 


9.4  System  Design  Documentation  It  is  important  that  the  system  design  is  properly  recorded  in 
documentation  usable  by  experts  other  than  the  initial  system  design  team.  MIL  STD'490 
identifies  document  outlines  suitable  for  this  purpose. 

ISSUE:  How  should  MIL-STO-490  be  used  to  record  the  system  design? 

GUIDANCE:  MIL-STD>490  identifies  many  different  specification  types  and  provides  outlines 
for  each  with  detailed  instructions  for  text  style,  wording  and  presentation.  Later  issues  of  MIL* 
STD-490  allow  greater  flexibility  for  use  of  contractor  format  documentation.  The  suggested 
use  of  MIL-STD-490  is  shown  in  *  gure  9-3.  This  requires  the  use  of  9  types  of  specification  A, 
B1.  B2.  B3,  B5,  Cib,  C2b.  C3.  2'’  '  05.  Their  use  is  briefly  explained  below.  Two  basic 
principles  should  always  be  applied  in  their  use: 

a  A  Top  Down*  design  should  be  employed.  The  design  should  not  commertce  until  an 
adequate  definition  of  requirements  has  been  determined. 

b.  Requirements  arxl  Design  should  be  separated.  This  allows  for  effective  design  review. 

9.4.1  Type  A  -  System  Specirication  This  document  should  be  used  during  the  concept  definition 
phase  (see  paragrsph  7i  to  collect  in  one  document  the  functiona:  requirements  of  the  AIS.  The 
Type  A  specification  should  contain  information  on  the  missions  supp<^ed  and  how  the  AIS  should 
function  through  those  missions.  The  Type  A  specification  may  be  used  to  descrft>e  the  whole 
aircraft  avionics  in  which  case  the  AIS  functions  will  constitute  a  section.  The  Type  A 
specification  may  not  be  continually  updated  throughout  the  AIS  oevelopment  and  constitutes  an 
initial  directnn  statement.  No  development  work  should  be  specified  by  the  Type  A  specification. 


9.4.2  Type  B1  Prime  Hem  Development  Specification  This  document  should  be  used  to  define 
the  spedfic  performance  and  design  requirements  of  the  AIS.  The  data  for  this  document  wM 
come  from  the  virork  decoflMd  in  paragraphs  7  and  8.  Content  of  the  B1  specification  should 
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include  those  items  Isted  below.  If  convenient  the  B1  specification  can  be  conrfiined  with  the  AIS 
Cib  specification  as  parts  I  and  II  of  the  same  volume. 

-  AIS  functions 

•  AIS  functional  performance 

-  AIS  external  interfaces 

•  Definition  of  existttg  equipment  performance  and  interlaces  where  these  are  lo  be  retafoed 

-  Design  constraints  (standards  etc) 

•  Testing  requirements 


Harewmrc 

DoCHMMlallM 


Firawmre 

DacMMCfiUlio* 


FIGURE  9.3  AIS  and  MIL-STD-490 

9-4.3  Type  B2  Critiriri  horn  Soecificaiion  These  documents  should  be  used  for  each  new  or 
modified  existing  equipment  the  AIS  to  determine  the  equipment  specific  performance.  Content 
sut^ects  are  therefore  simiiar  to  the  type  B1  specification.  For  the  system  descrfoed  in 
paragraph  9.5,  type  B2  specifications  would  be  required  for  the  PCE  and  SSEs. 
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9.4.4  Type  B3  Non-Coftmtex  Item  Develoomenl  Soedtjcation  These  documents  should  be 
generated  for  every  removable  module  to  be  developed  or  modHied  for  the  AIS.  Content  subiects 
are  therefore  similar  to  the  Type  Bt  specification  but  are  addressed  at  a  lower  level. 

9.4.5  Type  B5  Computer  Program  Develotynent  Soedfication  These  documents  should  be 
generated  for  every  separate  software  package  to  be  developed  for  the  AIS.  These  wil  be  broadly 
of  two  types;  application  software  and  equipment  firmware.  The  content  of  the  B5  specification 
may  overlap  significantly  with  documentation  required  by  C>OD-STD*2t67  and  therefore  such 
documentation  may  be  used  in  lieu  of  a  B5  specification.  Subject  area  for  inclusion  in  the  B5 
specification  (or  its  equivalent)  should  inclu^; 

Software  functions  Software  performance  (rates,  accuracies) 

Inputs  •  Outputs 

Testing  requirements  Processing  Limitations  (ips,  memory  etc) 

9.4.6  Type  Cib  Prime  Item  Product  Fabrication  Soedfication  This  document  should  be 
developed  in  respor^se  to  the  type  Bt  specification.  As  such  the  contents  are  similar  but  with  the 
emphasis  on  design  and  performance  achieved.  In  documenting  the  design  the  Cib  specification 
provides  for  design  review  against  Bt  specification  requirements  and  also  control  o' 
interchangeabUrty.  To  achieve  the  latter  cross  reference  has  to  be  made  to  specific  production 
drawirtgs  or  the  B2  specifications  of  the  AIS  equipments.  Content  therefore  includes: 

a  AIS  functions 

b.  AIS  performance 

c.  AIS  interfaces 

d.  Oefinttion  of  design  by  use  of  functional  explanations  of  how  AIS  equipments  and 
software  achieve  each  AIS  function  (System  Mechanisms) 

The  Ctb  specification  wUI  progressively  take  precedence  over  the  Bt  specification  as 
development  progresses. 

9.4.7  Typfl.C2  Cfilicat  Ham  Product  Funciign  Specificatipn  These  correspond  to  the  B2 
specifications  as  the  Ctb  corresponds  to  the  Bt  specification. 

9.4.8  Type  C3  Non  Complex  Item  Product  Fabrjcation  Specification  These  correspond  to  the  B3 
specifications  as  the  Ctb  corresponds  to  the  Bt  specification.  Note  however  that  much  testing 
here  will  be  by  inspection  and  demonstration. 

9.4.9  Type  CS  Computer  Program  Product  Spedfjcations  These  correspond  to  the  B5 
specifications  in  a  similar  manner  to  the  Ctb  •  Bt  relationship.  C5  specifications  will  be 
(tominated  by  DOD-STO-2t67  requirements. 

9.5  An  Example  System  This  example  system  is  included  to  show  the  impact  of  the  gutdttice 
given  previously  for  the  design  of  an  example  AIS.  For  the  purposes  of  this  example  the 
following  assumptiorts  have  been  made: 

a  The  System  is  applicable  to  differing  aircraft  applications. 

b.  Aircraft  avionics  architecture  is  based  on  'Pave  Pillar*  cortcepts. 

c.  The  system  is  applicable  to  new  aircraft  only  (not  compromised  by  retrofit 
consideration). 

d.  No  nudear  considerations  in  basic  design. 

e.  Previous  guidance  of  sect'ons  7  and  8  observed. 
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The  general  form  of  the  example  design  is  shown  in  figure  9.4  as  a  system  diagram.  The 
functions  of  the  AIS  have  been  implemented  with  the  SMS  function  and  are  partitioned  between 
five  equipment  types: 

Bulk  Memory  Process  Control  Equipments  (PCE) 

Critical  Controls  -  Remote  Store  Station  Equipments 

Fuselage  Store  Station  Equipments 

These  are  interconnected  via  a  High  Speed  Data  Bus  (HSDB)  and  an  Armament  Network.  These 
system  components  and  interfaces  are  descrbed  below. 

9.5.1  Bulk  Memory  This  is  a  central  bulk  memory  device  and  is  based  on  the  Pave  Pillar 
concepts.  It  is  used  to  retain  software  and  data  files  for  the  AIS  and  other  airaaft  systems. 

When  required,  software  artd  data  relevant  to  the  AIS  are  ‘downloaded^  to  the  AIS  processors 
using  the  High  Speed  Data  Bus.  Software  for  the  AIS  is  separated  into  two  distinct  parts.  These 
are  referred  to  as  Safety  Critical  and  non  Safety  Critical  software.  These  parts  can  be  separately 
and  independently  compiled  and  are  so  partitioned  to  enable  the  end  user  to  request  non  Safety 
Critical  software  changes  without  requiring  a  full  repeat  of  software  safety  analysis.  The  data 
files  for  the  AIS  contain  the  information  on  store  loadouts.  In  addition  data  files  on  Targets  and 
Trajectories  will  probably  be  included  to  enable  the  AIS  to  transfer  this  information  to  stores 
when  relevant. 

9.5.2  Process  Control  EquipmentsfPCEt  Two  Process  Control  Equipments  are  implemented  and 
provide  the  following  functions: 

a  Control  of  the  Armament  Network 

b.  Decision  processing  for  SMS  and  AIS  functions  including  critical  controls 

c.  Formatting  of  data  for  stores  and  other  avionics  systems 

d.  Recomputation  of  data  to  or  from  stores 

e.  Interface  to  avionics  data 

The  PCE  are  centrally  mounted  units  and  are  of  an  integrated  rack  form.  This  means  that  they 
may  have  no  distinct  physical  boundary  although  electrically  they  are  highly  independent  of 
other  avionics.  One  of  the  PCE  is  in  a  back  up  standby  mode  to  maintain  the  PCE  function  should 
a  failure  occur  in  the  primary  PCE.  For  safety  reasons  each  implements  its  own  Power  Supply 
and  Pl-Bu$  backplane.  With  one  exception,  all  of  the  modules  which  makes  up  a  PCE  are  standard 
modules  with  part  number  commonalty  with  other  avionics  system  modules.  The  exception  is  a 
module  which  provides  dedicated  safety  critical  discrete  interfaces  to  the  Critical  Controls  and 
the  Armament  Network. 

9  5.3  Critical  Controls  The  Critical  Controls  are  realized  as  discrete  switches  principally 
located  on  th  j  aircrew  tf,rottle  and  stick.  Other  controls  are  less  accessible  but  still  located  in 
the  cockpit.  They  are  directly  wired  to  the  AIS.  The  Critical  Controls  implemented  for  the  pilot, 
and  if  relevant  the  navigator,  are:  Air  to  Air  and  Air  to  Ground  Weapon  Release  controls,  Master 
Arm,  and  Selective  and  Emergency  Jettison  Controls.  Other  Critical  Controls  which  are 
implemented  include  those  for  gear  uo  and  locked  and  ground  test  override. 
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9.5.4  Store  Station  Equipment  (SSE^  To  reduce  the  hazards  of  long  signal  lines  connecting  to 
safety  critical  devices,  and  to  reduce  wiring  in  general,  Store  Station  Equipments  (SSE)  are 
implemented.  There  are  two  main  categories  of  SSE  referenced  to  as  'remote*  and  'core'  SSE. 

9.5.4.1  Remote  Store  Station  Equipment  The  remote  SSE  are  units  controlled  by  the  Armament 
Network  and  located  near  to  the  weapon  stations.  Where  two  or  more  weapon  stations  are  in  close 
proximity  the  SSE  can  be  of  multiple  station  capability.  Two  criteria  are  used  to  determine 
whether  station  will  be  implemented  by  adding  capacity  to  a  multiple  SSE  or  by  adding  a  new 
SSE; 


a  If  an  SSE  is  located  in  a  removable  structure  then  it  must  only  control  those  stations 
within  the  same  removable  structure 

b.  If  the  use  of  multiple  SSE  means  that  the  weapon  station  wiring  is  excessively  long, 
such  that  it  becomes  susceptible  to  electromagnetic  interference,  then  separate  SSE  are  required 

The  rentote  SSE  provide  the  following  functions: 

a  Interface  to  S  &  RE 

b.  Interface  to  Weapon  Bay  control  signals  (such  as  bay  door  opening) 

c.  Interface  to  the  following  MIL  STO-1760  signals:  Data  Bus,  Power,  Release  Consent, 
and  Interlock 

d.  Dedicated  Interfaces  to  existing  stores  (such  as  HARM  and  Maverick) 

e.  Discrete  signals  generic  to  many  existing  stores  (28  volt/O  volt  inputs  and  outputs) 

9  5.4.2  Core  Store  Station  Equipment  Two  SSE  located  in  the  'fuselage*  area  of  the  aircraft  are 
designated  as  Core  SSE.  Their  location  must  be  as  protected  as  possible  to  improve  the  reliability 
of  the  system.  They  must  be  fitted  in  all  aircraft  configurations.  The  core  SSE  implement 
identical  furtctions  to  the  remote  SSE  with  the  following  additions: 

a  Analog  Network  for  MIL-STD-1760  High  Bandwidth  and  Low  Bandwidth  signals 

b.  Power  Distribution  to  other  AIS  equipments 

c.  Sidewinder  guidance  signals  distributed  using  Analog  Network 

Each  core  SSE  provides  these  functions  for  one  of  two  groups  of  weapon  stations.  All  of  the 
weapon  stations  are  deterr^-  ed  as  odd  or  even  (usually  by  alternatively  allocating  SSE  as  'odd* 
or  "even"  progressing  left  to  fight  front  to  back  across  the  aircraft).  This  ensures  that  should 
one  fuselage  SSE  fail  then,  assuming  a  laterally  symmetrical  loadoul,  full  weapon  type  capability 
will  be  provided  with  only  the  numbers  of  available  stores  reduced.  To  provide  further 
redundancy  both  core  SSE  provide  power  to  each  remote  SSE. 

9.5.5  Hbh  Speed  Data  Bus  As  described  above  the  AIS  receives  software  and  loadout  data  by 
interface  to  an  avionics  HSDB.  This  bus  is  additionally  used  to  transfer  the  following  data: 

a  Aircraft  Data  (positions,  time  etc.) 

b.  Aircraft  and  Store  Target  Data  (as  may  be  required  for  MIL-STD-1760  stores) 

c.  Target,  Trajectory  and  Threat  Data  (as  may  be  required  for  MIL-STD-1760  stores) 

d.  Non-critical  Crew  Control  and  Display  Data 
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9.5.6  Armament  Network  To  provide  a  link  between  the  AIS  equipments  a  high  integrity 
Armament  Network  is  implemented.  This  includes  the  following: 

a  Data  Bus  -  Providing  a  MIL-STO-1553  data  bus  with  stubs  to  the  Store  Station 
Equipments.  Stubs  for  the  ASI  are  routed  through  the  SSE  to  enable  ASI  isolation  to  be 
implemented.  This  data  bus  conveys  the  majority  of  data  (critical  and  non-critical)  through  the 
AIS. 


b.  Discrete  signals  -  Providing  the  discrete  signals  defined  in  paragraph  9.3.4. 

c.  Power  signals  -  Dual  redundant  28  Volts  and  non-redundant  115  Volts  three  phase 
distributed  from  the  core  SSE  to  the  other  SSE  to  be  used  by  the  remote  SSE  for  switching  to 
their  local  ASIs  and  for  internal  power. 

d  Analog  •  Direct  connection  of  ASI  High  Bandwidth  and  l^w  Bandwidth  signals  from  the 
weapon  stations  to  the  core  SSE. 
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10.  HARDWARE  DESIGN  ISSUES  AND  GUIDANCE 


'^his  section  describes  those  issues  relevant  to  hardware  and  equipment  design  of  the  AIS. 
Particular  emphasis  is  placed  on  MIL-STD-1760  implementation.  The  following  subparagraphs 
are  included: 

MILSTD-1760A  Implementation  Guidance  10.1 

Detailed  Guidance  on  specific  design  issues  10.2 

10.1  MIL-STD-176QA  Implementation  Guidance  For  the  purposes  of  this  paragraph, 
MIL-STO-1760A  is  limited  to  the  April  198.S  Draft  as  modified  by  pages  IS  through  52a  of 
June  1 985  Draft  Notice  1 .  In  practice  discussions  and  guidance  relate  to  the  Sept  1 985  issue  of 
MIL-STD-1760A  plus  Notices  2  and  3.  Paragraphs  of  this  section  address  the  following 
subjects: 

High  Bandwidth  issues  MIL-STD-1553  issues 

Low  Bandwidth  issues  Discrete  Signal  issues 

Power  issues  Auxiliary  Signal  set  issues 

Connector  issues  Reserved  provisions  issues 

10.1.1  Hioh  Bandwidth  Issues  The  following  issues  are  considered:  High  Bandwidth  network  and 
Switching  Elements. 

10.1.1.1  High  Bandwidth  Network  This  is  broken  into  three  further  issues:  Centralized  or 
Distributed,  Switched  or  FDM  Technology,  and  Shared  Usage  (LB,  1553  or  other  signals), 

10.1.1.1.1  Centralized  or  distributed 

ISSUE:  Should  the  High  Bandwidth  Network  be  centralized  or  distributed? 

GUIDANCE:  In  general  a  centralized  system,  as  shown  in  Figure.  10.1.A,  is  recommended.  The 
major  factors  to  be  considered  when  deciding  what  type  of  network  to  implement  are; 

a  VSWR  The  VSWR  requirements  stated  in  MIL-STD-1760  of  1.75  maximum  for  all 
ASl-ASI  signal  paths  is  quite  stressing,  in  a  distributed  system,  as  shown  in  figure  10.1,  the 
number  of  switcii  elements  and  connectors  in  some  ASl-ASI  signal  paths  can  be  very  large 
making  it  difTicutt  to  guarantee  meeting  the  VSWR  requirements.  In  a  centralized  system,  as 
shown  in  figure  10.1,  the  number  of  switch  elements  and  connectors  can  be  limited  and  this 
makes  it  more  simple  to  guarantee  meeting  the  VSWR  requirement. 

b.  Amount  of  Aircraft  Wiring  The  amount  of  aircraft  wiring  required  to  implement  the 
two  types  of  networks  shown  in  figure  10.1  are  dependent  on  the  following  factors: 

-  Number  of  Network  paths  required  -  Number  of  ASIs  required 

-  Position  of  ASIs  -  What  Class  of  Interface  is  provided  at  a 

particular  AS  I 

c.  Broken  Networks  In  a  distributed  system  the  networks  are  "daisy  chained*  across  the 
aircraft.  If  one  of  the  equipments  in  the  chain  is  removed,  such  as  a  store  station  equipment 
fitted  in  a  removable  pylon,  then  High  Bandwidth  networking  is  also  removed  from  all 
equipments  further  down  the  chain.  This  problem  does  not  arise  in  a  centralized  network 
system. 
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FIGURE  10.1  Centralized  and  Distributed  High  Bandwidth  Networks 


10.1.1.1.2  Switched  or  FDM  Technology 

ISSUE:  Should  the  High  Bandwidth  Network  use  switched  or  FDM  Technology? 

GUIDANCE:  Use  of  switched  technology  is  recommended  because  the  present  state  of  FDM 
technology  makes  this  option  very  expensive  and  at  present  It  cannot  oope  w:th  the  transfer  of 
the  1 .6  GHz  type  B  signals.  However  FDM  technology  could  give  significant  savings  in  aircraft 
wiring  if  a  panlcular  aircraft  implementation  requires  many  network  paths  anu  this  may  make 
the  use  of  FDM  technology  more  attractive. 
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10.1.1.1.3  Sharfid  usaaa 

ISSUE;  Could  the  High  Bandwidth  Network  be  used  for  other  functions? 

GUIDANCE:  There  may  be  opportunities  to  use  the  networks  provided  for  the  High  Bandwidth 
signals  for  transfer  of  o*her  signals  particularly  certain  signals  from  existing  stores  (for 
example  the  video  signal  from  Maverick  AGM-6S  missile).  Great  care  must  be  taken  to  ensure 
that  these  signals  are  compatible  with  the  network  provided  for  High  Bandwidth  signals  and  that 
such  use  does  not  compromise  any  of  the  requirements  of  MIL  STD-1760.  Particular  areas  of 
concern  are:  the  effect  that  network  terminations  may  have  on  these  other  signals,  and  the  effect 
on  VSWR  and  attenuation  in  the  High  Bandwidth  network  if  additional  switch  elements  are 
required  to  accommodate  these  other  signals.  Against  this  are  the  potential  benefits  in  terms  of 
reduced  aircraft  wiring  and  potential  space  saving  within  equipments,  due  to  the  reduction  in 
circuitry  required. 

10.1.1.2  Switching  Elements  This  is  broken  into  four  further  issues: 

Type  B  signals  (1.6  GHz)  -  Type  A  signals  (20  MHz) 

Connectors  -  Cabling 

10.1.1.2.1  Type  B  signals  fI.eGHzi 

ISSUE;  What  type  of  switching  elements  should  be  used  for  Type  B  signals? 

GUIDANCE;  It  is  recommended  that  specialized  RP  relays  (for  example  Dynalech  type  D1 ,  M  or 
N)  be  used  for  switching  the  type  B  signals  as  other  switching  methods  will  make  it  difficult  to 
meet  the  VSWR  requirements.  The  use  of  multi-pole  relays  (as  shown  in  figure  1 0.2)  is 
recommended  to  reduce  the  overall  VSWR  figure  of  the  network. 

10.1.1.2.2  Type  A  signals  (2QMHz) 

ISSUE;  What  type  of  switching  elements  should  be  used  for  Type  A  signals? 

GUIDANCE;  It  is  recommended  that  high  quality  signal  relays  (MIL-R-39016)  be  used  for 
switching  the  type  A  signals,  as  these  are  relatively  inexpensive  and  can  provide  acceptable 
transfer  characteristics  to  meet  the  MIL-STD-1760  requirements.  Figure  10.2  shows  a  typical 
switch  configuration  for  the  Type  A  signal  paths. 

10.1.1.2.3  Connectors 

ISSUE:  What  type  of  connectors  should  be  used  for  High  bandwidth  signals? 

GUIDANCE;  It  is  recommended  that  whenever  possible  within  the  aircraft  wiring  and  AIS 
equipments,  separate  coaxial  connectors  should  be  used  for  all  High  Bandwidth  signals 
particularly  those  carrying  Type  B  signals  (1.6GHz).  An  example  of  a  suitable  connector  for 
HB1  signals  is  a  MIL-C-39012  SMA  type  connector.  Failing  that,  the  use  of  coaxial  contacts 
within  a  larger  connector  is  acceptable.  Examples  of  suitable  MIL-C-39029  contacts  for  use  in 
MIL-C-38999  connectors  are  for  HB1  and  HB2  specification  sheets  /1 02  and  /1 03;  for  HB3 
and  HB4  specification  sheets  /28  and  (75.  This  will  improve  the  overall  VSWR  characteristics 
and  reduce  interference  on  the  signal  lines. 
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Example  of  a  Type  B  (RF)  Network 
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Example  of  a  Type  A  Network 
FIGURE  1 0.2  Typical  High  Bandwidth  Switching  paths 


10.1.1.2.4  CabLnp 

ISSUE:  What  type  of  cables  should  be  used  for  High  Bandwidth  signals? 

GUIDANCE:  The  use  of  fow  loss  coaxial  cable  for  all  High  Bandwidth  signal  lines  is  required,  as  a 
minimum,  to  be  able  to  meet  the  ASI  to  ASI  attenuation  requirements  for  the  long  cable  lengths 
required  in  an  aircraft.  Examples  of  suitable  coaxial  cable  types  are  for  HB1  and  HB2  -  RG316 
cal^  and  for  HB3  and  HB4  -  RG179  cable.  Where  possfole  use  of  Triaxial  cable  is  recommended 
to  give  added  protection  gainst  interference  due  to  electric  or  magnetic  fields.  Examples  of 
suitable  triaxial  cable  types  are  for  HB1  and  H32  -  Tron^ter  TRC-50-2  and  for  and  HB4 
-  Trompeter  TRC-75-2. 
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10.1.2  MiL-STD-1553  Issues  The  following  issues  are  considered: 


Bus  Topology  Impact  of  Critical  Signals 

Hardware/Software  partitioning  -  Of^n  Circuit  Stubs 

10.1.2.1  Bus  Topology  Four  separate  bus  configurations  are  considered  here: 

-  Local  or  Aircraft  Bus  Single  or  Multiple  Buses 

Shared  Use  Linear  Bus  or  other  Topology 

10.1.2.1.1  Local  or  Aircraft  Bus 

ISSUE:  Should  the  MIL-STD-1553  bus  at  the  ASI  be  a  local  bus  or  part  of  a  common  aircraft 
bus? 

GUIDANCE:  It  Is  recommended  that  a  common  aircraft  bus,  as  shown  in  figure  10.3,  be  used  in 
preference  to  separate  local  buses.  The  use  of  separate  buses  for  each  ASI  requires  that  separate 
bus  control  circuitry  is  provided  for  each  ASI.  This  when  compared  with  the  common  bus 
approach,  will  increase  the  size  of  electronics  required,  reduce  the  overall  reliability  of  the 
system  and  add  on  extra  levels  of  complexity  to  the  overall  design.  One  advantage  of  using 
individual  buses  (figures  10.3)  Is  to  provide  isolation  of  the  bus  at  the  ASI.  This  is  necessary  to 
prevent  radiation  of  data  from  an  open  circuit  stub  subsequent  to  a  store  being  released. 

However,  isolation  of  the  ASI  can  easily  be  provided  by  other  means,  such  as  relays. 


Common  MIL-STD-1553  Stores  Bus 


Individual  MIL-STD-1553  Stores  Buses 
FIGURE  10.3  Local  and  aircraft  MIL-STD-1553  buses 
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10.1.2.1.2  Sifmte  or  Multiote  Buses 

ISSUE:  Should  single  or  multiple  buses  be  used  for  the  stores  bus? 

GUIDANCE:  A  single  dual  redundant  bus  is  recommended  in  preference  to  multiple  buses  (see 
figure  10.4),  unless  the  number  of  Remote  Terminal  addresses  required  cannot  be  accommodated 
on  a  single  bus.  A  single  bus  can  support  a  maximum  of  30  different  Remote  Terminal  addresses 
but  it  is  recommended  that  the  total  used  on  a  single  bus  be  limited  to  25  to  allow  some  room  for 
future  expansion.  A  single  bus  should  be  adequate  in  terms  of  bus  traffic  and  reliability  and  will 
minimize  the  amount  of  electronics  required  in  terms  of  numbers  of  bus  controllers. 

10.1.2.1.3  Shared  Use 

ISSUE:  Should  the  stores  bus  be  combined  with  other  MIL-STD-1553  aircraft  buses? 

GUIDANCE:  It  is  recommended  that  the  stores  bos,  wherever  possible,  be  combined  wKh  the  bus 
used  within  the  AIS.  Both  these  buses  r^uire  critical  da»a  to  be  transferred  and  both  need  to  bo 
under  the  control  of  the  AIS.  By  combining  these  buses  aircraft  wiring  is  reduced  and  fewer  bus 
controllers  are  required  and  this  will  reduce  tne  size  of  the  electronics  (see  Figure  10.5).  It  is 
not  recommended  that  the  stores  bus  be  combined  with  any  other  aircraft  bus  as  there  will  be  a 
conflict  between  the  types  of  data  to  be  transferred  which  could  make  it  difficult  to  meet  the 
requirements  for  critical  signal  transfer  on  the  stores  bus  (see  paragraph  10.1.2.2). 


Single  Bus  System 


Multiple  Bus  System 


FIGURE  10.4  Single  and  Multiple  Stores  Buses 
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Separated  Stores  Bus  and  Internal  AIS  Bus 


AVIOMCS  BUS 


Common  Stores  and  AIS  Bus 

FIGURE  10.5  Separate  and  shared  MIL  STD-ir53  buses 


10.1.2.1.4  Unaar  Bus  or  Other  Topoloav 

ISSUE:  What  topology  should  be  used  for  the  stores  bus? 

GUIDANCE:  A  linear  bus  (see  figure  10.6)  is  one  which  is  routed  through  the  aircraft,  including 
the  wings,  and  stubs  taken  from  the  bus  as  dose  as  possible  to  the  store  stations  and  remote 
units.  An  alternative  topology  is  for  the  bus  to  be  confined  to  the  fuselage  (see  figure  10.7). 

Mux  bus  wiring  from  an  ASI  on  the  wing  pylons  would  have  to  be  routed  down  the  length  of  the 
wing  to  a  stubbing  point  in  the  fuselage.  This  second  alternative  would  require  ttiore  aircraft 
wiring,  but  provide  greater  system  survivabiiity  of  battle  damage.  The  two  buses  in  a  dual 
redundant  system  could  8^  be  separated  making  it  very  unittieiy  that  both  are  destroyed  by  the 
sane  area  of  damage. 
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10.1.2.2  Impact  of  Critical  Signals 

ISSUE;  What  impact  does  the  requirement  to  transfer  critical  data  have  on  the  stores  bus? 

GUIDANCE:  MIL-STD-1760  requires  that  the  probability  of  injKlvertent  generation  of  a  valid 
critical  and  authority  word  demanding  critical  action  shaU  not  exceed  1  in  10^  flight  hours.  To 
meet  this  requirement  great  care  must  be  taken  to  design  a  bus  controller  of  high  integrity  for 
the  stores  bus.  See  oaragraph  1 0.2.2. 

10.1.2.3  Hardware/Software  partitionino 

ISSUE:  How  should  the  bus  control  furtction  be  partitioned  between  hardware  and  firmware? 

GUIDANCE:  The  actual  partitioning  between  hardware  and  firmware  is  for  the  designers  to 
determine,  but  they  should  be  aware  of  all  of  the  requirements  of  MIL-STD'1760  before 
deciding  on  this  partitioning.  The  following  gives  two  examples  of  requirements  that  need  to  be 
considered: 

a  1  in  10^  hours  critical  probability  quoted  in  10.1.2.2  above 

b.  The  AEIS  bus  controller  shall  be  capable  of  transmitting  commands  at  a  rale  such  that 
an  intermessage  gap  of  75Q  microseconds  maximum  can  be  supplied  when  needed.  This 
requirement  has  beien  removed  by  notice  3  thereby  allowing  a  more  stressing  requirement  to  be 
imposed  on  individual  aircraft,  that  is  as  short  as  50  microsecords  maximum. 

Figure  10.8  shovvs  a  typical  design  for  a  bus  controller.  The  following  irniicates  typical 
partitioning  of  functions  between  hardware  and  firmware: 

a  Hardware;  •  Checksum  generation  and  checking 

•  (Critical)  Authority  code  generation  (MIL'STD-1553) 

•  Protocol  error  handling 

b.  Firmware:  •  Data  bus  changeover 

-  Busy  management 

•  Status  word  excef^ion  handling 

-  Combining  safety  critical  and  non-critical  message  demands 

•  Insertion  of  Critical  Authority  code 

•  Safety  Critical  message  checks  to  include  inhibiting  any 
transmission  of  nuclear  weapon  subaddresses  to  any  ASI 

•  Checking  that  critical  control  and  authority  words  match  before 
enabling  transmission  of  Mission  Store  Control  Message 


10.1.2.4  Open  Circuit  Stubs 

ISSUE;  What  effect  does  open  circuit  stubs  have  on  the  design  of  the  stores  bus? 

GUIDANCE:  After  a  store  has  been  released,  the  MSI  er)d  of  the  umbilical  will  probably  remain 
exposed  arxl  therefore  able  to  rarSate  the  activity  on  the  mux  bus.  To  prevent  this,  the  stub 
providing  the  mux  bus  to  the  ASI  needs  to  be  isolated  folowing  store  release.  Some  methods  of 
isolation  are  shown  in  figure  10.9. 
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FIGURE  10.8  Typical  MIL-STD>1553  Bus  Controller 


FIGURE  10.9  Methods  of  isoialing  open  ckaM  tiutos 
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10.1.3  Low  Bandwidth  Issues  The  following  issues  are  considered:  networks,  switching 
elenfents,  and  connections. 

10.1.3.1  Network  This  is  broken  into  four  further  issues: 

Centralized  or  Distributed  •  Technology 

Shared  Usage  •  impact  of  Potential  Use  as  a  Low  Speed  Data  Bus 

10.1.3.1.1  Centralized  or  distributed 

ISSUE:  Should  the  Low  Bandwidth  Network  be  centralized  or  distributed? 

GUIDANCE:  A  centralized  system  is  recommended  (same  configuration  as  a  High  Bandwidth 
centralized  network  showm  in  figure  10.1)  to  provide  the  Low  Bandwidth  Network  in  the  same 
area  as  the  High  Bandwidth  Network  (see  paragraph  10.1.1).  However,  this  is  dependent  on  the 
particular  aircraft  implementation.  A  centralized  system  would  give  a  greater  aircraft  wiring 
weight,  but  in  a  distributed  system  where  the  network  is  "daisy  chained*  (figure  10.1),  the 
removal  of  a  unit,  such  as  a  pylon  mounted  Ptere  Station  Equipment,  would  result  in  the  loss  of 
the  Low  Bandwidth  network  to  units  further  down  the  chain. 

10.1.3.1.2  Technology 

ISSUE:  What  technology  should  be  used  for  the  Low  Bandwidth  Network? 

GUIDANCE;  Use  of  switched  technology,  such  as  relays,  is  recommended,  as  the  present  state  of 
FOM  technology  makes  this  option  very  expensive  and  it  is  unable  to  transmit  DC  levels  as 
required  by  MIL-STO-1760. 

10.1.3.1.3  Shared  Usage 

ISSUE:  Could  the  Low  Bandwidth  Network  be  used  tor  other  functions? 

GUIDANCE:  There  should  be  an  opportuni^  to  use  this  network  to  transfer  other  audio  signals 
particularly  signals  from  existing  stares,  for  example  the  audio  from  a  Sidewinder  AIM-9L 
missile.  Ttie  designer  should  ensure  these  signals  are  compatible  with  the  network  and  that  they 
do  not  compromise  the  requirements  of  MIL-STD-1760. 

10.1.3.1.4  Impact  of  potential  use  as  Low  Speed  Data  Bus 

ISSUE;  How  is  the  Low  Bandwidth  Network  affected  by  its  potential  use  as  a  Low  speed  Data  Bus? 

GUIDANCE:  It  is  recommended  that  if  the  Low  Bandwidth  network  were  to  be  used  as  a  low  speed 
data  bus,  the  bandwidth  of  the  network  should  be  increased  to  allow  signal  frequencies  between 
DC  and  1  MHz  to  be  passed.  Otherwise  the  use  of  this  network  as  a  low  speed  data  bus  should  rx}t 
greatly  impact  the  design  of  the  network,  as  the  existing  requirements  of  MIL-STD-1760  should 
ensure  that  this  network  can  support  being  used  for  this  purpose.  The  designer  should  be  aware 
cf  this  potential  additional  requirement  to  ensure  that  this  facility  can  easily  be  accommodated  in 
the  future. 

10.1.3.2  Switching  Elements 

ISSUE:  What  type  of  switching  elements  should  be  used  for  Low  Bandwidth  signals? 
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GUIDANCE:  It  is  recommended  that  signal  relays  conforming  to  MIL-R-39016  be  used  for 
switching  :he  Low  Bandwidth  signals,  as  semiconductor  switches  of  comparable  size  would 
significar^tly  degrade  the  signal. 

10.1.3.3  Connections  This  is  broken  into  two  further  issues;  connectors  and  cabling. 

10.1.3.3.1  Connectors 

ISSUE:  What  type  of  connectors  should  be  used  for  Low  Bandwidth  signals? 

GUIDANCE:  It  is  recommended  that  whenever  possible  twinaxial  or  triaxial  connectors  or 
triaxial  contacts  in  a  larger  connector  be  used. 

10.1.3.3.2  Cabling 

ISSUE:  Whai  type  of  cable  should  be  used  for  Low  Bandwidth  signals? 

GUIDANCE:  The  use  of  triaxial  or  twinaxial  csfole  is  recommended.  Two  coaxial  cables  with  the 
screens  tied  may  be  used  if  absolutely  necessary. 

10.1.4  Discrete  Signal  Issues  The  following  interfaces  are  considered: 

•  Release  Consent  Interlock 

•  Address  •  Structure  Ground 

10.1.4.1  Release  Consent  This  is  broken  into  three  issues:  Switching  Location;  Switching 
Design,  Elements  and  Location;  and  Internal  Information  Transfer. 

10.1.4.1.1  Switching  Location 

ISSUE:  Where  should  the  switching  elements  for  Release  Consent  be  located? 

GUIDANCE:  As  this  is  a  safety  critical  interface,  the  final  switch  elements  in  the  signal  path 
must  be  as  close  as  possible  to  the  ASI,  thereby  minimizing  the  possibility  of  electromagnetic 
interference  inadvertently  activating  the  interface.  The  return  for  Release  Consent  is  the  same 
line  as  used  for  28\  DC  Power  2  return.  It  is  therefore  recommended  that  the  switching  circuits 
for  28V  DC  Power  2  be  located  close  to  the  switching  circuits  for  Release  Consent. 

10.14.1.2  Switching  Design.  Elements  and  Location 

ISSUE:  What  guidance  can  be  given  for  the  design  of  the  switching  circuits  for  Release  Consent? 

GUIDANCE:  As  this  is  a  safety  critical  signal  the  design  of  the  switch  should  meet  the  normal 
requirements  for  such  signals  (see  10.2.1).  At  least  two  switch  elements  should  be  provided  in 
this  signal  path  as  shown  in  figure  10.11  to  ensure  no  single  fault  can  inadvertently  activate  the 
signal.  One  of  these  switch  elements  should  provide  an  air  break  for  protection  against  EMI  and 
the  second  switch  element  should  be  a  semiconductor  switch  for  protection  against  vibration. 
Care  should  be  taken  in  the  design  of  the  release  consent  switches  to  ensure  that  the  isolation 
requirement  of  MIL-STO-1760  (lOOKohms)  between  Release  consent  signals  at  different  ASIs 
is  met.  Special  consideration  should  be  given  to  the  design  of  the  BIT  circuit  for  this  signal,  to 
ensure  that  any  biasing  circuits  do  not  compromise  the  isolation  requirements. 
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10.1.4.1.3  Internal  Information  Transfer 


ISSUE:  How  does  Release  Consent  effect  internal  information  transfer  within  the  AIS? 

GUIDANCE:  It  is  recommended  that  Release  Consent  is  only  activated  after  a  positive  aircrew 
action  such  as  operation  of  Trigger.  This  operation  shouid  be  transferred  to  the  remote  unit 
using  discrete  signals,  so  that  interlocks  can  be  provided  on  the  release  consent  switching  circuit 
thereby  inhibiting  activation  of  the  output  unless  Trigger  is  operated.  This,  combined  with  the 
use  of  critical  data  transfer  on  the  internal  MIL-STD-1553  AIS  bus,  will  provide  a  high  level  of 
safety  on  this  critical  interface.  See  Figure  10.10. 


TRIOOER 

DISCRETE 


FIGURE  10.10  Release  Consent  Switching  Circuit 


10.1.4.2  Interlock  This  is  broken  into  two  issues;  monitoring  location  and  circuitry. 

10.1.4.2.1  Monitoring  Location 

ISSUE:  Where  should  the  Interlock  monitoring  circuitry  be  located? 

GUIDANCE:  It  is  recommended  that  the  interlock  signal  be  monitored  close  to  the  ASI  to  reduce 
aircraft  wiring.  The  Interlock  signal  may  be  used  directly  or  indirectly  to  remove  28V  DC 
power  from  the  store  for  deadfacing  the  connector  when  the  store  is  not  present.  If  Interlock  is 
tu  be  used  for  this,  then  it  is  recommended  that  the  monitor  circuit  tor  this  signal  be  close  to  the 
power  switching  elements  for  the  particular  ASI. 

10.1.4.2.2  Circuitry 

ISSUE:  What  guidance  can  be  given  for  the  designs  of  the  interlock  circuitry? 

GUIDANCE:  The  designer  should  be  aware  of  all  the  requirements  concerning  the  interlock 
interface  especially  if  this  interface  is  to  be  used  to  determine  store  presence.  If  this  is  the  case, 
the  designer  should  ensure  that  the  response  time  of  the  monitoring  circuit  to  changes  of 
Interlock  status  is  acceptable  for  the  overall  system  design  as  well  as  ensuring  all  the  voltage, 
current  and  threshold  requirements  of  MIL-STD-1760  are  met.  A  typical  Interlock  circuit  is 
shown  in  figure  10.11. 
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FIGURE  10.11  Typical  Interlock  Circuit 

10.1.4.3  Address  This  is  broken  into  two  issues;  fixed  or  variable  and  determined  at  ASI  or 
Equipment. 

10.1.4.3.1  Fixed  or  Variable 

ISSUE:  Should  the  Address  discretes  have  fixed  or  variable  value? 

GUIDANCE:  It  is  strongly  recommended  that  fixed  addresses  are  used  to  identify  the  Renxite 
Terminal  address  at  all  ASIs.  If  variable  addresses  are  used  it  would  degrade  the  safety  of  the 
system  when  considering  the  transfer  of  safety  critical  information  on  the  MIL>STD-1553  Mux 
Bus. 

10.1.4.3.2  Determined  at  ASI  or  Eaulpment 

ISSUE:  Where  should  the  RT  Address  of  an  ASI  be  determined? 

GUIDANCE:  The  Address  should  be  determined  at  any  convenient  point  in  the  aircraft  that  is  non- 
interchangeable.  For  example,  as  shown  in  figure  10.12,  if  there  is  an  ASI  in  a  removable 
structure  the  address  determination  circuitry  should  not  be  located  in  the  structure  itself,  but 
the  wiring  should  be  routed  through  the  structure  to  address  determination  circuitry  located  in 
the  non-removable  structure.  This  will  prevent  the  possibility  that  simply  by  exchanging 
structures  two  different  ASI  could  be  allocated  the  same  RT  Address  (see  also  13.1.2.3). 

10.1.4.4  Structure  Ground 

ISSUE:  What  guidance  can  be  given  for  the  Structure  Ground  signals? 

GUIDANCE:  This  signal  should  be  connected  to  aircraft  structure  ground  at  the  closest  convenient 
point  to  the  ASi.  This  signal  is  only  used  to  mmimize  shock  hazard  to  personnel  and  must  not  be 
used  as  a  normal  signal  or  power  return  path.  The  ASI  to  MSI  umbilical  cable  should  have  an 
overall  screen  which  should  be  bonded  to  the  shell  of  the  connectors  at  either  end.  thereby 
providing  a  structure  ground  path  to  the  store,  capable  of  carrying  the  currents  generated  by 
lightning  strikes  etc. 
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ADDRESS  DETERMINATION 
CIRCUITRY 


10.1.5  Power  Issues  The  following  primary  power  issues  are  considered: 

a  Centralized/Oistributed 

b.  Elements 

c.  Connections 

1  Signal  Specific  Design 

10.1.5.1  Centralized  or  dlstrlbpled  This  is  broken  into  two  further  issues:  switching  and  fault 
isolation. 


10.1.5.1.1  Switching 

ISSUE:  Should  the  power  switching  circuitry  be  centralized  or  distributed? 

GUIDANCE;  It  is  recommended  that,  wherever  possible,  the  power  switching  elements  be  located 
close  to  the  ASI  particularty  for  28V  DC  Power  2  which  should  be  considered  as  the  safety 
critical  supply.  However,  if  there  are  limiting  factors,  such  as  lack  of  space  in  a  pylon,  then 
some  of  these  power  switching  elements  could  be  located  centrally.  As  shown  in  figure  10.13,  a 
centralized  system  would  require  more  aircraft  wiring  compared  with  a  distributed  system. 

10.1.5.1.2  Fault  Isolation 

ISSUE:  Where  should  the  fault  isolation  elements  for  the  power  signals  be  located? 

GUIDANCE:  It  is  recommended  that,  wherever  possible,  the  fault  isolation  elements  should  be 
located  close  to,  but  before,  the  switching  elements  as  shown  In  figure  10.14.  Tnis  will  allow 
the  fault  isolation  element  to  be  monitored  by  the  internal  AIS  BIT  without  having  to  activate  the 
switch  elements  and  thus  apply  power  to  the  store.  This  means  the  state  of  all  the  circuit 
breakers  in  the  system  can  be  obtained  by  the  AIS  before  the  aircrah  is  airborne  allowing  any 
corrective  action  to  be  taken  before  the  star!  of  a  mission. 

10.1.5.2  Elements  This  is  broken  into  two  further  issues;  Power  Switches  and  Isolation 
Elements. 
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10.1.5.2.1  Power  Switches 

ISSUE:  Wh«?t  type  of  power  switching  elements  should  be  used? 

GUIDANCE:  Mechanical  power  relays  to  MIL-R-6106  should  be  used  for  the  switching  of  power 
as  the  voltage  drops  associated  with  solid  state  power  switching  devices  would  make  it  very 
difficult  to  meet  the  requirements  of  MIL-STD-1760. 

10.1.5.2.2  Isolation  Elements 

ISSUE:  What  type  of  fault  isolation  elements  should  be  used? 

GUIDANCE:  Circuit  Breakers  conforming  to  MIL-STD-1498  should  be  used  for  the  isolation 
elements  in  the  power  lines  as  other  devices,  such  as  fuses,  cannot  meet  the  current-time 
profiles  specified  in  MIL-STO-1760. 

10.1.5.3  Connections  This  is  broken  into  two  further  issues:  connectors  and  cabling. 

10.1.5.3.1  Connectors 

ISSUE:  What  guidance  can  be  given  for  the  connectors  to  be  used  for  power  interfaces? 

GUIDANCE:  It  is  recommended  that  power  interface  lines  should  be  routed  through  connectors 
with  the  largest  contacts  practical  to  reduce  voltage  drops,  that  is  use  size  1 6  contacts  or  larger 
wherever  possible. 

tO.1. 5.3.2  Cabling 

ISSUE:  What  guidance  can  be  given  for  the  cabling  to  be  used  for  Power  signals? 

GUIDANCE:  It  is  recommended  that  the  largest  cable  that  is  practical  be  used  for  all  power 
wiring  to  reduce  the  voltage  drops  through  the  cable,  that  is  use  size  16  AWG  or  larger  wherever 
possible. 

Signal  Specific  Deskm  This  is  broken  into  three  further  issues:  28V  DC  Power  1. 

28V  DC  Power  2.  and  1 15V  AC. 

10.1.5.4.1  26V  DC  Power  1 

ISSUE:  What  specific  guidance  can  be  given  for  28V  DC  Power  1? 

GUIDANCE:  This  signal  should  be  treated  as  a  non-crilical  power  interface  that  can  be  applied  to 
the  store  at  any  time. 

ISSUE:  What  specific  guidance  can  be  given  for  28V  DC  Power  2? 

GUIDANCE:  This  interface  should  be  treated  as  a  safety  critical  supply  and,  as  shown  figure 
10.15,  it  is  recommended  that  this  be  interlocked  with  an  aircrew  operated  switch,  such  as 
Master  Arm,  such  that  It  cannot  be  activated  until  there  has  been  a  positive  action  by  the 
aircrew.  The  designer  should  also  be  aware  that  the  return  for  28V  DC  Power  2  is  also  used  as 
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the  return  for  Release  Consent.  This  could  aNect  the  way  these  functions  are  partitioned  within  a 
Store  Station  Equipment. 


HARTEN  ARM 
OWCRETE 


FIGURE  10.15  28V  DC  Power  2  Control 


10.1.5.4.3  115V  AC 

ISSUE:  What  specific  guidance  can  be  given  for  115V  AC? 

GUIDANCE:  This  interface  should  be  treated  as  a  non-critical  power  supply  that  can  be  applied  to 
the  store  at  any  time.  It  is  reccmmended  that  ail  three  phases  be  switch^  together  to  reduce  the 
circuitry  required  for  power  switching  and  to  reduce  the  time  slew  between  the  switching  of 
individual  phases.  If  this  signal  is  to  be  used  to  power  stores  that  only  require  a  single  phase 
(such  as  the  AiM-S  Sidewinder  missiles),  then  the  designer  must  consider  the  implications  of 
having  the  remaining  two  pf.ases  active  l^t  not  connected.  In  this  case  separate  switch  elements 
on  each  phase  could  be  used  or  additional  switch  elements  introduced. 

10.1.6  Auxiliary  Signal  Set  Issues  The  following  issues  are  considered: 

Auxiliary  Power  Switching/Isolation 
Auxiliary  Interlock  Monitoring 
Auxiliary  Structure  Ground 

10.1.6.1  Auxiliary  Power  This  is  broken  into  two  further  issues:  28V  DC  and  115V  AC. 

10.1.6.1.1  2fiy_DC 

ISSUE:  What  guidance  can  be  given  for  Auxiliary  28V  DC? 

GUIDANCE:  The  same  recommendations  apply  to  Auxiliary  28V  DC  power  as  given  for  primary 
28V  DC  Power  2  In  10.1.5  abwo.  However  the  size  of  the  switching  and  isolation  elements 
required  for  Auxiliary  power  may  make  it  impractical  to  distribute  the  circuitry  especially 
within  small  pylons. 
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10.1.6.1.2  USY.AC 

ISSUE:  What  guidance  can  be  given  for  Auxiliary  1 15V  AC? 

GUIDANCE:  The  same  recommendations  apply  to  Auxiliary  115V  power  as  given  for  primary 
1 15V  power  in  10.1 .5  above.  However  the  size  of  the  switching  and  isolation  elements  required 
for  Auxiliary  power  may  make  it  impractical  to  distribute  the  circuitry  especially  within  small 
pylons. 

10.1.6.2  Auxiliary  Interlock  Mor:itoring 

ISSUE:  What  guidar>ce  can  be  given  for  Auxiliary  Interlock  monitoring? 

GUIDANCE:  The  design  of  the  auxiliary  interlock  circuitry  should  be  similar  to  that  used  for  the 
primary  interlock  signal  discussed  in  10.1.4.2  and  shown  in  figure  10.12.  It  is  recommended 
that  the  monitor  circuit  be  located  close  to  the  ASI  to  reduce  aircraft  wiring.  The  designer  should 
be  aware  that  this  monitor  may  be  used  directly  or  indirectly  to  remove  auxiliary  28V  DC  power 
from  an  ASI  to  deadface  the  connector  when  store  absence  is  detected. 

10.1.6.3  Auxiliary  Structure  Ground 

ISSUE:  What  guidance  can  be  given  for  the  Auxiliary  Structure  Ground  signal? 

GUIDANCE:  This  signal  should  be  connected  to  aircraft  structure  ground  at  the  closest  convenient 
point  to  the  ASI.  This  signal  is  only  used  to  minimize  shock  hazards  to  personnel  and  must  not  be 
used  as  a  normal  signal  or  power  return  path.  See  the  guidance  given  for  primary  Structure 
Ground  in  10.1.4.4. 

10.1.7  Connector,  issues  The  following  two  issues  are  considered:  the  primary  connector  and 
the  auxiliary  connector. 

10.1.7.1  Primary  Connector  This  is  broken  into  two  further  issues:  High  Bandwidth  Contacts 
and  other  guidance. 

10.1.7.1.1  High  Bandwidth  Contacts 

ISSUE:  What  contacts  should  be  used  for  High  Bandwidth  signals  in  the  primary  connector? 

GUIDANCE:  It  .las  been  found  that  contacts  produced  against  specification  sheets  /28  and  /75  to 
MIL-C-39029  cannot  be  guaranteed  to  meet  the  VSWR  requirements  for  Type  B  signals  as 
specified  in  MIL-STD-1760.  For  both  High  Bandwidth  1  and  High  Bandwidth  2  signals  contacts 
built  to  the  following  specification  sheets  should  be  used  in  place  of  the  /28  and  /75  contacts 
specified  in  MIL-STD-1760.  Specification  sheet  102  for  the  pin  contact  and  specification  sheet 
1 03  for  ihe  socket  contact. 

10.1.7.1.2  Other  Guidance 

ISSUE:  What  other  guidance  can  be  given  for  the  primary  connector? 

GUIDANCE:  Great  care  needs  to  be  taken  if  cable  clamps  are  to  be  used  on  the  backshells  of  the 
primary  connector.  As  shown  in  figure  10.16  the  triaxial  contacts  extend  relatively  far  from 
the  rear  of  the  connector  insert  and  incorrect  cable  clamping  can  put  stress  directly  on  these 
contacts  which  can  physically  bend  or  move  them.  This  causes  slight  mismatches  when  the 
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connectors  are  mated  resulting  in  excessive  wear.  If  cable  damps  are  required  on  the  back  of  a 
connector  then  the  use  of  a  spacer  is  recommended,  to  ensure  these  particular  contacts  cannot  be 
distorted. 


CONTACTS  FORCED 
APART  AT  MATING 
FACE  OF  CONNECTOR 
CAUSING  A 
MISALIGNMENT  WITH 
MATING  CONNECTOR 


INSERT  SPACER 
BETWEEN  TRIAXIAL 
CONTACTS  BEFORE 
CLAMPING 


Possible  Solution 

FIGURE  10.16  Cable  Clamping  on  Primary  Connector 


10.1.7.2  Auxiliary  Connector  No  particular  guidance  is  offered  for  this  connector. 

10.1.8  Reserved  Provisions  Issues  The  following  issues  are  considered:  Fiber  Optics  and 
270V  DC. 

10.1.8.1  Fiber  Optic  This  is  broken  into  two  further  issues:  connector  contacts  and  hardware 
provisions. 

10.1.8.1.1  Connector  Contacts 

ISSUE:  What  provisions  should  be  made  in  terms  of  connector  contacts  for  the  Ftoer  optic 
signals? 

GUIDANCE:  The  connector  cavities  for  the  ASI  and  the  umbilical  (with  MSI  as  applicable)  should 
only  be  fitted  with  "plugs.*  Because  of  the  lack  of  suitable  ferrules,  no  attempt  should  be  made  to 
preempt  future  "contact*  designs. 

10.1.8.1.2  Hardware  Provision 

ISSUE:  What  hardware  provisions  should  be  made  lor  the  Fiber  optic  signals? 

GUIDANCE:  No  specific  hardware  provision  need  be  provided  sqMtrt  from  ensuring  spare  moduto 
positions  are  available  in  the  central  control  equipments. 
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10.1.8.2  27QV  DC  This  is  broken  into  three  further  issues:  hardware,  connector,  and  cabling 
provisions. 

10.1.8.1.2  Hardware  Provisions 

ISSUE:  What  hardware  provisions  should  be  made  for  the  270V  DC  signals? 

GUIDANCE:  Ensure  spare  space  is  available  in  all  store  station  equipments  to  incorporate  a  270V 
DC  switch  function. 


10.1.8.2.2  Connector  Provistons 


ISSUE:  What  connector  provisions  should  be  made  for  the  270V  DC  signals? 

GUIDANCE:  Insert  size  16  socket  or  pin  contacts  as  defined  by  slash  sheet  /56  arKf  /58  to 
MIL-C-39029,  as  appropriate,  at  all  ASI  connectors.  Ensure  ail  store  station  equipments 
provide  enough  spare  contacts  on  their  external  connectors  to  allow  for  incorporation  of  270V 
DC  switching  function  within  the  equipment. 


10.1.8.2.3  Cabling  Provisions  Ensure  spare  wires  are  provided  in  cable  runs  between  each  ASI 
connector  and  the  appropriate  store  station  equipment  and  provide  spare  wires  in  cable  runs 
from  each  store  station  equipment  to  central  power  distribution  equipment. 

10.2  Detailed  Guidance  on  Soocific  Issues  Guidance  is  provided  on  the  following  subjects: 


•  Safety  Critical  Switching 

•  Use  of  Standard  Modules 
Connectors 

Physical  design  of  equipment 


Safety  Critical  Data  Transfer 
Built  in  Test  Circuitry 
Connector  Pin  Allocation 

Electromagnetic  considerations  (EMC,  EMP,  TEMPEST) 


10.2.1  Safety  Critical  Switching  The  issues  discussed  in  this  section  give  general  guidance  for 
the  design  of  all  safety  critical  output  circuits  within  the  AIS  but  have  particular  relevance  to 
the  design  of  the  circuits  to  control  the  MIL-STD-1760  Release  Consent  signal  as  this  is  classed 
as  a  safety  critical  output. 


10.2.1.1  Number  of  Switch  Elements 


ISSUE:  How  many  switch  elements  should  be  provided  in  safety  critical  signal  paths? 

GUIDANCE:  There  should  be  at  least  three  switch  elements  under  the  control  of  the  AIS  between  a 
power  source  and  any  safety  critical  output  as  shown  in  Figure  10.17.  This  allows  each  switch 
element  to  be  exercise  j  for  BIT  purposes  while  still  ensuring  that  no  single  fault  could 
inadvertently  activate  a  safety  critical  output  as  discussed  in  10.2.4.3. 

10.2.1.2  PosiUon  of  switch  elements 

ISSUE:  Where  should  the  switch  elements  in  the  safety  critical  signal  paths  be  located? 

GUIDANCE:  As  a  minimum  the  final  switch  element  in  a  safety  critical  signal  path  should  be 
positioned  as  dose  to  the  store  Interface  as  possiWe.  This  minimizes  the  risk  that  the  safety 
critical  signal  could  bo  activated  by  electromagnetic  pick  up  in  the  wiring  to  the  store  Interface. 
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MV  OC  POWER 


FIGURE  10.17  Safety  Crftical  Switch 


10.2.1.3  Type  of  switch  elements 

ISSUE:  What  type  of  switch  elements  should  be  used  in  the  safety  critical  signal  paths? 

GUIDANCE:  The  final  switch  element  in  any  safety  critical  signal  path  should  be  of  a  mechanical 
type  which  creates  an  air  break  in  the  signal  path.  This  affords  protection  against 
electromagnetic  interference  activating  the  safety  critical  output.  One  of  the  other  switch 
elements  in  the  signal  path  should  be  of  a  semiconductor  type,  if  possi)ie.  This  affords  greater 
protection  against  vforation  compared  with  the  mechanical  type  of  switch  and  also  allows  for 
greater  control  of  the  actual  switching  time  than  can  be  achieved  by  using  mechanicai  switch 
elements. 

10.2.2  Safely .  Critical  data  .transter 

ISSUE:  What  guidance  can  be  given  for  the  transfer  of  safety  critical  data  on  the  MIL-STD-1553 
bus? 

GUIDANCE:  MIL-STD-1760  defines  two  pairs  of  words  for  transfer  of  safety  critical  data.  The 
first  word  In  the  pair  is  a  Critical  Control  Word  containing  the  actual  safety  critical 
information.  The  second  word  in  the  pak  is  a  Critical  Authority  Word  whidi  is  a  polynomial  code 
check  on  the  critical  data  bits  in  the  Critical  Control  Word.  MIL-STD-1760  also  specifies  an 
extremely  low  probability  that  valid  Criticai  Control  and  Authority  words  can  be  generated  in 
error.  To  achieve  this  requkement  the  processing  for  generating  the  control  word  shotM  be 
separate  and  completely  independent  of  ttie  proce^ng  for  generating  the  authority  word.  One 
method  of  achieving  this  separation  is  shown  in  figure  10.18.  The  central  control  processor 
nr^Hors  the  state  of  the  criticai  switch  inputs  (such  »  MAS,  Trigger,  Weapon  Release,  EJ,  SJ) 
and  when  it  identifies  that  a  change  of  criticai  state  is  requked  the  processor  gofferates  the 
relevant  critical  control  word.  Thte  Critical  control  word  is  then  passed  to  the  Bus  Controfier 
tor  transmission  on  the  MIL-STO-1553  ^ores  Bus.  The  Bus  Controller  identifies  that  a  crftical 
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Authority  word  is  required  and  reads  this  word  from  an  authority  code  t^le.  However  access  to 
this  authority  code  table  is  limited  by  separate  (fiscrete  monitors  from  the  critical  switch  irtputs 
therefore  access  can  only  be  obtained  to  those  codes  relevant  to  the  critical  state  presently 
demanded  by  the  critical  switches,  for  example  codes  associated  with  jettison  demands  are  only 
available  if  SJ  or  EJ  has  been  selecled. 

10.2^  Use  of  Standard  Modules 

10.2.3.1  Process  Control  EQuioment  fPCEt 

ISSUE:  Can  standard  modules  be  used  in  the  Process  Control  Equipments? 

GUIDANCE:  The  use  of  standard  modules  within  the  PCE  is  dependent  on  the  particular  aircraft 
requirements.  However,  if  the  avionics  architecture  for  a  particular  aircraft  is  based  on  ‘Pave 
Pillar,*  then  the  PCE  could  utilize  standard  modules  to  perform  the  following  functions: 

Power  Supply  Unit  (PSU)  Central  Processing  Unit  (CPU) 

Memory  •  MIL  STD-1553  Bus  Control 

10.2.3.2  Store  Station  Equipments  fSSEi 

ISSUE:  Can  standard  riKidules  be  used  in  Store  Station  Equipments? 

GUIDANCE:  The  differing  physical  and  environmental  constraints  between  aircraft  and  even 
between  different  pylon  positions  on  the  same  aircraft  means  that  each  SSE  is  likely  to  be  unique. 
However,  there  is  scope  for  developing  small  standard  modules  which  could  be  used  in  many 
different  SSE.  Examples  of  such  rrKXluies  are:  MIL-STD-1S53  Remote  Terminal  Module, 
Processing  and  Control  Module,  High  Current  Switch  Module  (Relays  and  FETs).  Power  Supply 
Module. 


FIGURE  10.18  Safety  Critical  Data  Transfer 
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10.2.4  Built  in  Test  Circuitry 

ISSUE;  What  guidance  can  be  given  for  BIT  circuitry  in  the  AIS? 

GUIDANCE;  The  actual  additional  circuitry  required  to  perform  BIT  wiH  be  monitor  circuits  to 
ensure  particular  furtctiorts  are  being  activated  when  demanded  and  some  addWonal  circuits  to 
excite  system  inputs  ur>der  control  of  the  central  processor.  The  following  subparagraphs 
describe  the  BIT  circuits  which  may  be  added  to  enable  particular  types  of  signals  to  be  tested. 

10.2.4.1  Discrete  Input  BIT  The  circuit  shown  in  hgure  10.19a  could  be  used  lor  BIT  on 
Discrete  input  signals  such  as  Interlock.  High  and  low  input  states  of  the  input  receiver  can  be 
tested  by  ckiving  the  BIT  signal  high  and  low. 

10.2.4.2  Discrete  Output  BIT  The  circuit  shown  in  figure  10.19b  could  be  used  lor  BIT  on 
Discrete  output  circuits.  Each  output  type  will  have  a  grouped  monitor  signal  and  during  BIT 
each  output  will  be  individually  set  active  and  monitored  functionally. 

10.2.4.3  Safety  Critical  Cutout  BIT  The  circuit  shown  in  Figure  10.19c  could  be  used  for  BIT 
on  safety  critical  output  circuits  such  as  Release  Consent.  During  BIT  each  output  will  be  tested 
by  first  ensuring  all  switches  (x.  y  and  z)  are  open,  then  in  turn  demanding  short  'on'  states  lor 
switches  y  and  z,  ensuring  BIT  monitor  2  changes  state  each  time.  A  short  'on'  state  is  demanded 
for  switch  x  while  ensuring  BIT  monitor  1  changes  stale.  This  method  exercises  each  switch 
element  while  ensuring  no  single  fault  could  cause  the  output  to  become  active. 

10.2.4.4  AnaloQ  Network  BIT  The  circuit  shown  in  figure  10.19d  could  be  used  for  BIT  of  analog 
network  circuitry  as  required  for  the  High  Bandwidth  and  Low  Bandwidth  networks  of 
MIL-STD-1760.  BIT  for  these  circuits  is  limited  to  monitoring  the  analog  element  drive  signal. 

10.2.4.5  Power  Switch  BIT  The  circuit  shown  in  figure  10.19e  could  be  used  for  BIT  of  power 
switches  as  would  be  required  lor  28V  DC  Power  1.  2BV  DC  Power  2.  115V  AC.  Auxiliary  28V 
DC  and  Auxiliary  1 1 5V  AC.  BIT  for  these  switohes  will  be  by  monitoring  the  output  voltage  (AC 
or  DC)  to  verify  the  :xxrect  state  has  been  achieved. 

10.2.5  Connectors 

ISSUE;  What  guidance  can  be  given  for  connectors  to  be  used  within  the  AIS? 

GUIDANCE:  Wherever  possible  external  equipment  connectors,  that  is  those  not  used  for  the  ASI, 
should  be  of  a  comnton  type  and  conform  to  accepted  standards,  such  as  MIL-C-38999. 

10.2.6  Connector  Pin  Altocations 

ISSUE:  What  guklance  can  be  given  for  the  allocation  of  signals  to  connector  contacts  within  ttie 
AIS  not  currently  controlled  by  MIL-STD-1760,  that  is  not  the  ASI? 

GUIDANCE:  The  designer  should  ensure  that  all  safety  critical  signals  are  surrounded  by  "Guard 
contacts'  as  shown  in  Figure  10.20.  These  "Guard  contacts'  are  either  kept  at  or  dose  to  groimd 
potential  or  they  are  open  circuit.  This  ensures  that  adjacent  pki  shorts  within  a  oonrteclor 
cannot  activate  a  safety  critical  signal  into  or  out  of  a  unit.  Wherever  possUe  sigr\ds  capable  of 
carrying  high  voltages  or  high  currents  should  be  separated  from  other  types  of  si(^ 
preferably  by  routing  them  through  separate  connectors. 
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Guard  Pins 


10.2.7  Physical  Design  of  Eauipment 

ISSUE:  What  guidance  can  be  given  for  the  physical  design  of  equipment  within  the  AIS? 

GUIDANCE:  This  is  highly  dependent  on  particular  aircraft  requirements  and  philosophies 
although  the  designer  should  ensure  that  wherever  possible  all  circuitry  associated  with  high 
current  and  voltages  should  be  physically  separated  from  other  types  of  signal. 

10.2.8  Electromagnetic  Considerations  fEMC.  EMP.  TEMPEST) 

ISSUE:  How  is  the  design  of  the  AIS  affected  by  electromagnetic  considerations? 

GUIDANCE:  The  following  guidance  is  offered  for  the  signal  types  specified  in  MIL*STD-1760. 

10.2.8.1  High  Bandwidth  fHBI  Signals  Triaxial  cable  should  be  used  for  all  HB  signal  lines, 
the  outer  shield  being  terminated  at  a  convenient  point  on  the  shell  of  the  connector  the  signal  is 
passing  through.  Voltage  limiting  devices  should  be  used  on  the  signal  lines  as  they  enter 
equipments  to  suppress  any  spikes  or  surges  generated  by  Electromagnetic  pick  up  in  the  wiring. 

10.2.8.2  Mux  Bus  Voltage  limiting  devices  should  be  used  on  these  signals  as  they  enter 
equipments  to  suppress  any  spikes  or  surges  generated  by  electromagnetic  pick  up  in  the  wiring. 
All  black  data  being  transmitted  on  the  bus  should  be  encrypted.  Whenever  a  store  has  been 
released  the  stub  routed  to  the  associated  ASi  should  be  isolated  to  ensure  that  data  cannot  be 
radiated  from  the  MSI  connector  on  the  umbilical. 

10.2.8.3  Low  Bandwidth  signals  Voltage  limiting  devices  should  be  used  on  the  signal  lines  as 
they  enter  equipments  to  suppress  any  spikes  or  surges  generated  by  electromagnetic  pick  up  in 
the  wiring. 

10.2.8.4  Release  Consent  Filter  contacts  should  be  used  for  those  signals  in  the  external 
connectors.  Voltage  limiting  devices  should  also  be  used  as  descrfoed  above. 

10.2.8.5  Address  Discretes  The  wire  lengths  used  for  these  links  should  be  kept  to  a  minimum. 

10.2.8.6  Power  Filter  contacts  should  be  used  on  all  the  power  interfaces. 


224 


11.  SOFTWARE  GUIDANCE 


This  section  offers  guidance  for  the  implementation  of  the  MIL-STD-1760  Loc’cal  T  ssig  ; 
Definition  (LDO).  Paragraph  11.1  discusses  specific  LDD  issues,  paragraph  11.2  disc»<s.;es 
nxire  general  software  issues  important  to  the  development  of  software  ^  '  n  > .  >  and  paragraph 
1 1.3  summarizes  the  overall  benefits  offered  by  the  LDD  to  AIS  software  Th  s  .section  is 
intended  to  be  used  by  experienced  software  designers  and  managers.  In  many  cases  the  following 
assumptions  are  made  of  the  reader: 

a.  Experience  of  real  time  embedded  system  software 

b.  Knowledge  of  a  High  Order  Language  (HOL)  such  as  Ada,  Jovial  or  Pascal 

c.  Knowledge  of  general  Stores  Management  System  characteristics 

d.  Experience  of  MIL-STD-1553  protocol  implementation  in  software 

e.  Good  understanding  of  MIL-STD-1760  (refer  to  section  5) 

11.1  MIL-STD-176Q  LDD  IMPLEMENTATION  This  paragraph  considers  the  effects  on  the  AIS 
software  design  imposed  by  the  MIL  STD-1760  LDD.  The  guidance  and  rationale  have  an 
aircraft  AIS  emphasis  and  are  concerned  with  both  the  low  level  software  effects  of  the  protocol 
required  by  the  LDD  and  the  effects  on  the  apf^ication  software  imposed  by  the  LDD.  Where  there 
are  differences  between  the  contracted  June  1985  Draft  Notice  1  LDD  and  the  later  Notices  2  and 
3  then,  where  possible,  guidance  and  rationale  is  provided  for  each  issue,  (denoted  by  Notice  1 
and  Notice  2/3).  Where  there  are  no  significant  differences,  then  a  single  set  of  guidance  and 
rationale  is  provided,  (denoted  by  Notice  1/2/3).  Issues  and  guidance  are  structured  to  the  same 
outline  as  the  main  LDD  features  described  in  paragraph  5.  Specifically  guidance  is  provided  for 
the  following  topics; 

•  Overa'i  LDD  Impact 
Subaddress  Allocation 
Store  Identification 
Basic  Protocol 

•  Coordinate  systems 

•  Standard  Data  Formats 
Mass  Data  Transfer 

11.1.1  Overall  LDD  impacts  This  paragraph  offers  high  level  guidance  for  the  implementation 
of  the  LDD  within  an  AIS. 

11.1.1.1  Generic  Software 

ISSUE:  Should  the  AIS  implement  a  generic  software  solution  applicable  to  the  management  of  all 
MIL-STD-1760  mission  stores  or  implement  specific  solutions  tailored  to  each  mission  store 
type? 

GUIDANCE:  To  maximize  the  benefits  of  the  LOO  in  Increasing  interoperability  and  reducing 
software  and  integration  costs,  then  every  effort  within  the  AIS  software  design  should  be  made  to 
develop  generic  software  modules.  This  applies  particularly  in  the  following  areas: 

Power  Up  Sequences  •  Store  Determinations 

Safety  Critical  Control  Error  Determination 

Error  Recovery  Standard  Data  Entities 

Standard  Message  Bui.ding  and  decoding 


-  Power  Up  Sequence 

•  Data  Check  Algorithm 

•  Safely  Critical  Control  and  Monitor 

•  MIL-STD-1553  Option  restrictions 

-  Entity  Definitions 

-  Base  Message  Formats 
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It  is  not  possible,  with  the  current  limited  scope  of  the  LDD,  to  construct  truly  generic  AIS 
software. 

RATIONALE:  Although  the  MIL-STO-1760  LDD  does  not  mandate  the  structuring  of  generic 
subprograms  for  these  key  LDD  areas,  it  is  essential  that  provision  is  made  within  the  software 
development  cycle  to  consider  structuring  of  effective  generic  subprograms,  that  is  software 
units  that  handle  protocols  in  a  general  purpose  manner  without  requiring  constant  interface 
reviews.  To  realize  the  real  benefits  in  terms  of  greater  interoperability  and  reduced  system 
procurement  costs,  the  AIS  must  utilize  generic  software  modules.  These  modules  should  be  seen 
as  primarily  generic  to  many  stores  but  specific  to  one  AIS  implementation.  Clearly  it  will  be 
possible  to  write  software  that  is  generic  to  many  AIS  implementations,  but  achievement  of  this 
will  be  more  difficult  and  is  beyond  the  scope  of  the  immediate  goals  of  MIL*STD>1760.  Once  an 
AIS  implementation  has  embodied  the  recommended  set  of  generic  modules,  then  when  a  new  store 
is  added  to  the  aircraft  a  relatively  small  amount  of  software  should  require  change  or  new 
generation.  This  is  shown  in  figures  11.1  and  11.2.  Clearly  in  figure  11.2  more  effort  and  time 
will  be  consumed  and  furthermore  the  confidence  in  the  final  software  will  be  lower,  because  a 
higher  proportion  of  unproven  software  wilt  be  utilized.  These  arguments  are  strongest  in  the 
area  of  safety  critical  control.  As  discussed  later  in  1 1.1.6  the  designer  should  consider 
partitioning  the  software  so  that  safety  critical  software  is  rarely  changed  and  therefore  repeats 
of  lengthy  software  safety  analyzes  can  be  avoided.  Should  a  non  generic  safety  critical  control 
module  be  used,  then  new  modules  will  be  required  for  each  new  store  type  each  requiring  a  full 
and  lengthy  software  safety  analysis. 

1 1 .1 .2  Power  Do  Sequence  This  section  offers  guidance  for  software  designed  to  power  up 
multiple  mission  stores. 

11.1.2.1  Store  Power-Up  Timing 

ISSUE:  When  should  mission  stores  be  first  powered  up? 

BACKGROUND:  Mission  stores  are  entitled  to  flag  errors  if  the  power  application  is  in  the  wrong 
order,  or  if  incorrect  time  sequencing  is  performed.  In  some  cases  this  could  lead  to  a  hang-jp 
situation. 

GUIDANCE:  To  enable  store  identification  to  take  place,  the  aircraft  must  power  up  and 
interrogate  the  store  well  in  advance  of  the  store's  possible  employment.  Wherever  possible, 
this  should  take  place  when  the  aircraft  is  not  airborne. 

RATIONALE:  Many  AIS  functions  will  be  commanded  over  MIL-STD-1553  data  links.  By  their 
time  division  multiplexing  nature  these  links  can  be  slow.  The  power  application  will  frequently 
be  penormed  by  relays.  These  relays  will  require  a  finite  turn  on  time,  say  20  msec  and  the 
monitor  cycle  may  take  a  further  20  msec.  With  the  serial  transfer  time,  each  power  source 
may  require  50  msec  for  application  and  monitor.  The  first  power  source  will  to  turned  on 
after  30  msec  giving  a  total  available  lime  of  120  msec  for  the  transfer. 

11.1.2.2  Reduction  of  power  up  time 

ISSUE:  Software  design  to  minimize  system  configuration  time  from  power  up. 

GUIDANCE  Notice  1/2/3:  The  software  design  should  ensure  that,  where  power  permits,  all 
mission  stores  are  powered  up  at  the  same  time  such  that  the  busy  times  associated  with  initial 
power  application  can  run  concurrentiy.  This  will  ensure  the  system  is  ready  in  the  shortest 
possible  time.  A  typical  timing  diagram  is  shown  in  figure  1 1 .3. 


226 


Notes;  The  generic  mission  store  controller  uses  data  representations  of  the  mission  store 
implementation  to  drive  general  purpose  software  to  achieve  specific  LDD  elements.  However 
some  specific  software  will  be  required. 

FIGURE  11.1  Software  Changes  for  New  Store  (Generic  Software  Structure) 


RATIONALE  Notice  1/2/3;  Mission  stores  must  complete  the  initial  power  up  processing  within 
500  ms  during  which  time  the/  can  be  in  a  valid  busy  state.  A  sequential  power  rouline  where, 
for  example  10  mission  stores  are  to  be  identified,  would  take  5  seconds  to  complete  thereby 
slowing  down  system  readiness.  This  could  prove  critical  for  in  flight  power  up  after  power 
failure. 

11.1.2.3  Error  Checking 

ISSUE:  What  error  checking  should  be  made  by  an  AIS  during  mission  store  power  up? 

GUIDANCE  Notice  1/2/3;  The  mission  store  power  up  phase  is  considered  to  start  with 
application  of  power  to  the  store  and  end  with  either  the  successful  receipt  of  a  store  description 
message  by  the  AIS  or  the  expiration  of  the  500  ms  limit  lime.  Additionally,  a  mission  store 
monitor  message  should  be  scheduled  at  the  point  where  it  is  available  and  valid  (described  in  the 
ICD  under  Notice  3)  to  ensure  the  critical  monitor  word  is  clear  and  the  checksum  check  is 
passed.  During  this  phase  the  following  checks  should  be  made: 

a  No  detected  power  overload  (such  as  by  exception  from  continuous  AIS  BIT  software) 

b.  MIL-STD-15S3  response  within  limit  time 

c.  No  MIL'STD-1553  error  (word  count,  bit  count,  parity  etc) 

d.  Busy  state  removed  within  limit  time 

e.  No  service  request/vector  word  combinations  beyond  AIS  handling  capability 

f.  Valid  mission  store  monitor  message  checksum 
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Note:  Each  routine  is  dedicated  to  a  mission  store  type 


FIGURE  1 1 .2  Software  Changes  for  New  Store  (Non-Generic  Software  Structure) 
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FIGURE  11.3  Power  Up  Timings 

If  the  500  ms  valid  busy  time  expires,  the  AIS  should  schedule  a  Reset  Terminal  Mode  code.  If 
busy  is  still  set,  schedule  retries  for  10  ms  before  failing  the  mission  store.  This  is  shown  as  a 
flow  chart  In  figure  11.4. 

RATIONALE  Notice  1/2/3:  Although  the  LOO  specifies  that  the  busy  bit  should  be  cleared  within 
500  ms  of  power  up,  a  tolerance  should  be  applied  by  the  AIS  to  ensure  that  mission  stores  are 
not  shut  down  without  the  AIS  scheduling  retries.  The  reset  mode  code  will  remove  any 
recoverable  latch  up  conditions  in  the  store.  If,  during  the  mission  store  power  up  sequence,  a 
non  fatal  error  Is  detected  the  AIS  must  action  the  reported  failure  either  by  hanging  the  store  or 
only  allowing  operation  in  a  degraded  nfK>de. 

11.1.3  Subaddress  Allocation 

ISSUE:  Allocation  of  subaddress  to  stores  and  remote  Interface  units. 

GUIDANCE  Notice  1/2/3:  The  AIS  software  should  be  designed  to  provide  additional  integrity 
checks  to  ensure  that  only  subaddresses  provided  within  the  store  interface  (via  upload  notice  l , 
via  ICO  Notice  2/3)  are  used.  Special  care  Is  required  with  the  Safety  critical  subaddresses. 
These  are  07  and  11  for  Notice  1  and  11,  19,  and  27  for  Notice  2/3.  Specific  recommendations 
are: 


a  Provide  high  integrity  checks  to  avoid  generation  of  messages  to/from  subaddresses 
reserved  for  NUCLEAR  WEAPONS  unless  initiated  by  Nuclear  certified  software. 

b.  Provide  high  integrity  checks  such  that  all  messages  to  subaddress  1 1  (critical 
control)  have  a  low  probability  of  either  inadvertent  generation  or  inadvertent  command  of  an 
undesired  critical  state  with  a  correctly  formatted  critical  authority  word. 
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FIGURE  1 1 .4  Power  Up  Flowchart  for  one  Store 

As  discussed  in  section  10,  these  checks  can  be  embodied  into  the  MIL-STD-1553  Bus  Controller 
firmware  as  well  as  the  AIS  software.  It  is  likely  that  some  standard  MIL*STD-1553  modules 
for  integrated  racks  will  not  implement  suitable  firmware  checks.  In  these  cases,  a  double  check 
will  have  to  be  implemented  in  the  AIS  software.  As  this  may  not  be  an  easy  task  it  is 
recommended  that  consideration  is  given  to  .AIS  requirements  when  designing  'standard" 
MIL*STD*tS53  hardware. 

RATIONALE  Notice  1/2/3:  Provision  is  made  by  ttte  LDD  for  predefined  subaddress  allocation 
(for  example  subaddress  1 1  for  safety  critical  control  and  monitor  messages)  leaving  a  wide 
range  of  user  definable  messages.  The  AIS  software  and  firmware  will  have  knowledge,  for  each 
store  determined  to  be  present,  of  the  implemented  and  critical  subaddresses  and  can  provide  an 
integrity  check  before  the  transaction  request  is  accomplished. 

11.1.4  Data  Check  Algorithm 

11.1.4.1  Checksum  Generation  Point 

ISSUE:  Should  the  checksum  generation  be  implemented  in  software? 

GUIDANCE  Notice  1/2/3:  Implement  the  AIS  checksum  generation  and  checking  in  software.  This 
may  be  either  the  AIS  software  or  MIL-STD-1553  Bus  Controller  firmware  if  that  is  switchable 
(on/off  and  algorithm)  by  the  AIS  software. 

RATIONALE  Notice  1/2/3:  Although  the  LOD  checksum  can  be  Implemented  in  hardware  the 
flexibility  of  the  software  implementation  should  be  exploited  particularly  when  interfacing 
with  either  mission  stores  not  implementing  a  checksum  on  spedfic  subaddresses  or  an  existing 
store  (for  example  AMRAAM)  which  does  not  ln^}lement  the  LOD  checksum  but  uses  another 
algorithm.  The  LDD  data  check  algorithm  is  readily  implemented  in  any  16  bit  computer  or 
microprocessor  ISA.  The  main  instructions  required  are  16  bit  exclusive  OR  and  16  bit  logical 
rotation.  Where  a  microprocessor  does  not  feature  a  logical  rotate  this  can  be  effected  by  uskig 
the  following  ‘instructions*  (shown  here  on  register  A). 
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BEGIN  AODAtoA 

JUMP  IF  NO  CARRY  to  END 
INCREMENT  A 
B€) 

A  coding  for  implementing  checksums  in  MiL-STD-1750  assembler  is  shown  below.  For  a  32 
word  message,  encoding  time  is  about  120  uS  maximum. 


Start 

LIM 

R3,1 

;  define  shift  left  (FF  or  OF  «  shift  right) 

LIM 

R1,mm 

;  load  with  number  of  message  words,  (not  including 
checksum  word) 

LIM 

R12,nn 

;  with  address  of  message  word  1 

XORR 

R2,R2 

;  clear  R2 

Codel 

)CR 

R2,0,R12 

:  Moduto  2  summing 

SCR 

R2,R3 

:  shift  left 

AISP 

R12,1 

;  increment  word  address 

SOJ 

Rl.Code  1 

;  decrement  word  count  -t-  JNZ 

STB 

R12,0 

;  store  checkword  in  last  word 

11.1.4.2  LDP  ChecksiiOLComoutation 

ISSUE:  What  are  the  effects  of  computing  the  LOD  Checksum? 

GUIDANCE  Notice  1/2/3:  Where  possible  implement  the  checksum  algorithm  in  the 
MIL-STD-1553  Bus  Controller  firmware.  As  discussed  in  paragraph  11.1.4.1,  this  would  be 
repeat  single  word  algorithm  of  some  3  x  16  bit  microprocessor  instructions.  The  algorithm 
would  be  inserted  in  the  time  available,  between  interfacing  with  the  MIL-STD-1553  protocol 
hybrids,  during  data  transmission. 

RATIONALE  Notice  1/2/3:  Software  interfaces  with  MIL-STO-1553B  protocol  hybrids  will 
generally  be  through  assembler  level  instructions.  Within  the  Ada  programming  language  there 
are  no  suitable  constructs  to  generate  efficiently  the  LDD  checksum  required  for  specified 
messages.  Implementation  in  firmware  frees  the  application  message  building  software  from 
computing  the  checksum.  It  should  also  be  noted  that  where  system  time  is  embedded  within  a 
message,  then  the  checksum  would  be  best  latched  in  at  transmission  time,  in  order  to  avoid 
excessive  compensation  processing  at  the  moment  of  building  /  queuing.  This  would  require  the 
computation  of  a  checksum  at  trans.mission  time. 

11.1.5  Store  Identification 

11.1.5.1  Use  Of  store  description  protocol 

ISSUE:  What  effects  upon  software  design  are  Imposed  by  the  store  description  protocol? 

GUIDANCE  Notice  1 :  The  AIS  should  follow  the  extraction  protocol  and  data  flow  shown  in  figure 

1 1 .5  to  determine  which  TX  subaddresses  and  which  RX  subaddresses  have  been  implemented. 
The  message  implementations,  provldod  as  data  entity  codes,  should  be  stored  in  a  Rextole  data 
structure.  An  example  data  structure  Is  provided  in  figure  1 1 .6.  The  information  held  about 
mission  store  message  implementation  can  then  be  used  by  general  purpose  message  building  and 
decoding  modules,  which  use  the  data  entity  code  to  access  an  entity  data  base,  it  will  be 
necessary  for  the  software  designer  to  include  store  specific  software  which  knows  In  which 
context  the  Implemented  messages  are  required.  Care  should  be  taken  within  the  resulting  data 
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FIGURE  11.5  Notice  1  Subaddress  Processing 


TABLE 


FIGURE  11.6  Data  Structure 
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base  design  to  allow  storage  capacity  for  multiple  data  of  the  same  entity  type,  such  as  multiple 
targets,  where  each  would  use  the  same  entity  code. 

RATIONALE  Notice  1 :  The  use  of  data  entity  codes  to  descrbe  message  structures  allows  the 
development  of  general  purpose  modules  to  build  messages  for  transmission  to  stores  and  decode 
incoming  store  sourced  messages.  These  generic  modules  can  only  be  effectively  developed  if  they 
have  access,  using  the  unique  data  entity  o^.  to  an  entity  data  base.  A  purely  generic  design  is 
not  possible  as  no  information  is  supply  from  the  mission  store  about  the  context  of  each 
declared  message.  Overlaying  data  onto  the  same  entity  oode  requires  consideration  during  the 
entity  data  base  design  and  access  efficiency  is  particularly  important,  because  the  message 
building/decoding  modules  could  be  frequently  executed  arid  any  excessive  delays  or  processing 
requirements  would  then  adversely  effect  AIS  performance. 

GUIDANCE  Notice  2/3:  Represent  the  Mission  Stores  ICD  in  a  suitable  data  structure  in  such  a 
manner  that  general  purpose  message  building  and  decoding  modules  can  be  used.  Here  the  ICD 
defines  the  use  of  standard  data  entities  instead  of  the  Notice  1  store  description  upload.  Care 
must  be  taken,  because  with  Notice  3  there  is  scope  for  the  use  of  non  standard  data  entities. 

RATIONALE  Notice  2/3:  Notice  2/3  LDD  allows  implementation  of  user  definable  subaddresses  to 
be  described  by  a  mission  store  ICO  instead  of  being  loaded  from  the  mission  store.  To  meet  the 
goals  of  reductions  in  software  and  system  integration  cost  on  aircraft  programs,  it  is  important 
that  the  aircraft  software  design  solution  provides  generic  subroutines  which  can  be  used  for 
message  building/processing  arxJ  data  word  formatting  and  decoding.  Excluding  user  definable 
data  words,  which  can  be  included  in  a  stores  ICD  under  special  conditions  provided  by  the 
standard,  these  routines  can  be  developed  for  the  standard  data  entities  and  called  from  a  generic 
mission  store  control  module(s)  which  uses  ICDs  represented  by  a  standard  data  structure. 

11.1.5.2  Inventory  Data  Base  Structure 

ISSUE;  How  should  the  AIS  inventory  data  base  be  structured  to  best  use  the  store  description 
data? 

GUIDANCE  Notice  1/2/3:  Provision  should  be  made  within  the  inventory  data  structure  for  the 
direct  inclusion  of  the  Country  Code  and  Store  Identity  or  ASCII  string  words  (Notice  1). 

Standard  software  modules  should  be  capable  of  decoding  these  three  store  description 
parameters  to  determine  the  exact  store  type.  The  inventory  structure  should  be  capable  of 
dealing  with  any  mission  store  for  which  interface  details  are  known  (through  Mission  Store  ICD 
under  Notice  2/3)  for  any  pylon  station.  The  structure  of  this  inventory  data  should  then  be 
used  for  selection  of  specific  stores  following  store  type  selection  requests. 

RATIONALE  Notice  1/2/3:  These  store  description  parameters  are  the  only  information  provided 
to  determine  the  interface  requirements  of  a  mission  store.  Standard  routines  should  be 
developed  that  can  identify  the  store  arxJ  then  dynamically  configure  the  system  inventory 
accordingly.  This  is  essential  If  the  AIS  is  to  configure  its  control  structures  on  uploaded 
information  which  then  reduces  the  requirement  on  the  ground  crew  to  load  in  the  inventory. 

This  potentially  increases  aircraft  readiness  times. 

11-1 -6  Safety  Critical  Control/Monitor  This  section  offers  guidance  on  the  way  the  AIS  should 
manage  the  safety  critical  data,  what  additional  software  interlocks  can  be  provided  and  the  best 
way  to  structure  the  software  to  use  the  safety  aitical  states  provided. 
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11.1.6.1  Usage  of  Standard  Software 

ISSUE:  Can  standard  safety  critical  software  for  control  of  Mission  Stores  be  used? 

GUIDANCE  Notice  1/2/3:  The  standard  safety  critical  message  and  word  structure  lends  itself  to 
the  development  of  dedicated  software  modules  where  few  changes  would  need  to  be  generated  and 
validated.  The  designer  should  ensure  that  standard  software  modules  are  used  in  the  AIS  to  build 
and  decode  safety  critical  messages. 

RATIONALE  Notice  1/2/3:  In  addition  to  the  benefits  in  critical  software  reduction  offered  by 
standard  routines,  containing  all  critical  message  processing  in  one  module  offers  advantages  in 
the  software  validation  and  verification  activities  required  to  prove  safety  critical  software 
control  systems. 

11.1.6.2  Software  Structure 

ISSUE:  What  software  structure  should  be  used  for  safety  critical  processing? 

GUIDANCE:  Safety  Critical  processing  should  be  structured  to  partition  safety  critical  software 
from  non  safety  critical  software  where  possible  and  always  separate  the  coinputation  of  critical 
authority  codes  from  the  generation  of  critical  control  words.  This  approach  is  shown  in  figure 
1 1 .7.  Here  the  AIS  processing  is  separated  into  four  elements: 

a  Non  critical  software  associated  with  targeting  data,  aircraft  data,  inventory  and 
other  functions.  The  end  user  may  wish  to  frequently  change  the  precise  functionality  in  these 
areas.  Software  verification  and  validation  will  be  required,  but  no  special  Safety  Critical 
analysis  will  be  required. 

b.  Safety  critical  software  associated  with  determining  the  critical  stale  of  the  store.  As 
specified  in  paragraph  8.2.2  these  states  are  highly  dependent  on  the  critical  switch  inputs. 

There  is  a  relatively  infrequent  need  to  modify  this  software,  because  of  the  generic  nature  of 
this  function.  Therefore,  although  any  modifi^tion  would  require  a  lengthy  and  detailed  software 
safety  analysis,  it  will  rarely  delay  implementation  of  a  new  store  on  the  aircraft  and  contribute 
little  to  life  cycle  cost.  The  output  from  this  software  will  be  the  critical  control  messages  for 
the  mission  stores  and  similar  messages  to  control  remote  AIS  equipments.  To  prevent  a  single 
processing  failure  from  being  capable  of  initiating  a  critical  event  the  safety  critical  software 
should  not  contain  the  algorithm  for  computing  the  critical  authority  data  words.  Because  the 
Mission  Store,  and  remote  AIS  equipments,  will  check  for  the  correct  authority  code  to  match  the 
critical  control  state  demanded,  this  software  package  alone  cannot  initiate  critical  action. 

c.  Codes  Processing  function  -  This  is  a  simple  software  or  firmware  function.  It 
receives  the  critical  switch  inputs  to  the  AIS  and  computes  from  them  only  those  critical 
authority  code  combinations  that  are  potentially  valid.  For  example  if  Master  Arm  te  not  Hve 
then  any  authority  code  associated  with  arming  comntands  would  not  be  computed  by  the  codes 
processing  function.  The  codes  processing  function  also  determines  which  critical  control 
formats  are  valid  (allowed  states)  for  the  detected  states  of  the  critical  inputs.  For  example  if 
Master  Arm  is  not  live  then  D7.  D8  and  DIO  of  the  Critical  Control  Word  would  not  be  allowed. 
The  codes  processing  cannot  initiate  a  safety  critical  message  and  therefore  a  single  processing 
failure  cannot  cause  a  safety  critical  event. 

d  Bus  Controller  firmware  •  As  previously  descrft}ed  in  paragraphs  10  and  11.1.3,  the 
Bus  Controller  firmware  exeojtes  certain  chedts  on  critical  message  transfer.  For  mission 
store  control  messages,  the  Bus  Controller  firmware  executes  the  following  sub  functions: 
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FIGURE  11.7  Separated  Safety  Criticai  Processing 


-  Combination  of  data  output  from  the  Safety  Critical  arid  codes  processing  functions 

•  Inhtoition  of  the  message  if  Safety  Critical  processing  output  does  not  match  the  allowed 
critical  states  output  from  the  codes  processing 

-  Channeling  of  safety  critics^  and  non  criticai  message  demwKls  onto  the  scene 
MIL  STD-1553  Bus 
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Since  the  Bus  Controller  firmware  contains  neither  the  critical  control  message  format  nor  the 
critical  authority  code  algorithm,  a  single  processing  failure  will  be  unable  to  initiate  an 
executable  safety  critical  message.  The  term  'separated.*  as  applieo  to  this  processing,  is 
subjective  and  needs  further  guidance.  One  extreme  position  is  where  the  four  processing 
elements  are  implemented  as  four  separate  equpments.  This  is  rejected  because  any  separation 
into  different  equipments  would  add  cost  and  weight.  Also  this  would  be  pointless,  because  for 
safety  reasons  the  interfaces  between  the  equipments  would  require  extensive  software  design 
verification  and  analysis.  Another  extreme  position  is  for  all  the  processing  to  be  executed  in  the 
same  processor.  These  would  be  separate  tasks  separated  only  by  the  tasking  implementation. 
With  such  an  implementation,  it  would  be  extremely  difficult,  or  even  impossible  to 
demonstrate  that  no  single  failure  could  initiate  a  safety  critical  action.  The  recommended 
solution  is  a  compromise  betwreen  these  two  positions  and  provides  high  performance  and  safety 
with  minimum  cost  and  weight  penalty.  The  recommendations  are.  in  order  of  importance: 

-  The  safety  critical  processing  and  codes  processing  must  be  executei  on  separate 
processors  with  fully  verifiable  irtdependent  design  and  compilation. 

-  The  Bus  controller  software  should  be  implemented  as  a  function,  executed,  designed 
and  compiled  separately  from  the  safety  critical  processing.  Where  this  is  not  possS)le.  such  as 
if  a  standard  MIL'STD-1553  module  is  mandated,  then  this  software  should  be  executed  on  the 
same  processor  as  the  safety  critical  processing,  but  should  be  separately  designad  and  compiled. 

-  fhe  non  safety  critical  software  must  be  designed  and  compiled  separately  from  the 
other  software.  It  may  be  executed  by  the  same  processor  as  the  safety  critical  software,  but 
ideally  a  separate  processing  module  should  be  used. 

11.1.6.3  Usaoe  of  Monitor  Messages 

ISSUE:  How  should  the  AIS  use  safety  criticai  monitor  messages? 

GUIDANCE  Notice  1/2/3:  After  any  aircraft  initiated  change  of  the  Store  Critical  State,  a 
monitor  of  successful  attainment  of  the  demarto  should  always  be  scheduled.  Sufficient  time 
should  be  allowed  to  enable  the  mission  store  to  attain  the  demarxled  state. 

RATIONALE  Notice  1/2/3:  Safety  critical  controls  require  a  higher  degree  of  integrity  checking 
than  other  mission  store  controls.  Any  change  in  the  mission  stores  safety  critical  state,  wttich 
can  only  be  initiated  by  the  safety  critical  control  message,  should  always  be  checked  to  prevent 
further  safety  critical  state  changes  being  initiated  until  the  current  state  is  attained.  If  the 
state  is  not  attained  within  the  expected  time,  or  an  incorrect  state  arises,  then  a  re-sequendng 
of  the  safety  critical  state  can  be  attempted.  Persistent  failure  to  attain  a  demanded  state  can 
then  result  in  the  mission  store  being  shut  down.  Demanded  slate  attainment,  within  mission 
stores,  may  require  the  activation  of  some  devices  which  could  take  a  consider^}le  time  to 
become  active.  For  example,  a  relay  may  be  used  to  switch  a  safety  critical  signal  and  account 
should  be  taken  of  the  settling  time,  typicaily  20  ms,  before  monitoring  for  successful 
attainment. 

11.1.6.4  SflliYtafa  Design  ter  Slats  Cgnirel 

ISSUE:  What  software  design  is  required  to  si^>port  safety  critiral  state  control? 

GUIDANCE  Notice  1/2/3:  The  misston  store  critical  state  control  should  be  irr^mented  in  the 
AIS  software.  As  descrtoed  in  11.1.6.2  tNs  software  should  have  three  portions: 
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a  AIS  safety  critical  software,  to  generate  MIL'STD-1760  mission  store  control 
message  data,  excluding  critical  authority  codes. 

b.  AIS  firmware  to  generate  allowed  critical  authority  codes. 

c.  AIS  MIL-STD-I.'SSS  Bus  Controller  firmware,  to  check  allowed  codes  against 
demanded  states,  insert  codes  in  messages  and  recompute  checksums. 

This  paragraph  considers  the  safety  critical  sottware.  SpecHic  guidance  points  are: 

a  Use  interrupts  as  the  mechanism  for  detection  of  relevant  critical  switch  changes. 
This  will  reduce  response  times. 

b.  Reverify  critical  inputs,  at  interrupt  scheduled  critical  input  processing  modules. 

c.  Avvcid  the  use  of  Ada  exceptions. 

d.  Implement  safety  critical  soft.vare,  not  as  one  generic  package,  but  rather  as  a  set  of 
generic  software  modules  spread  over  a  multi-layered  structure.  The  lower  the  layer,  the  more 
generic,  to  stores  and  different  AIS  functions,  the  software  can  be.  Successively  lower  layers 
should  implement  the  following  functions: 

High  level  state  determination 
Mapping  of  high  level  state  to  MIL-STD-1760  states 
MIL-STO-1760  State  sequencing 
MIL-’STO-1760  critical  data  formatting 

e.  Use  finite  state  control,  see  paragraph  1  i. 1.6.5,  for  critical  slate  determination. 
11.1.6.5  Software  Design  Technioues 

ISSUE:  What  software  design  techniques  should  be  employ^  1  for  aitical  stale  control? 

G  JIOANCE  Notice  1/2/3:  Exploit  finite  state  design  for  mission  store  control.  Map  other  control 
requiramer.ls,  for  the  mission  store  and  tne  release  and  suspension  controls,  to  the  available 
safety  critical  states. 

RATIONALE  No*ice  1/2/3:  The  safety  critical  states  offered  by  the  safety  critical  control  word 
are  natural  release  sequence  states  and  lend  themselves  to  the  development  of  a  finite  state 
machine  at  the  heart  of  tha  AIS  software  design.  This  is  a  proven  and  reliable  method  of  control 
system  software  design.  As  the  AIS  controls  mission  stores  through  the  release  cycle,  other 
message  activity  is  required,  such  as  the  transmission  of  targeting  messages  to  slew  a  missile 
s^er  head  to  the  sensed  target  position.  Matching  these  message  path  controls  to  the  sa'ety 
critical  states,  allows  ft’!!  mission  store  control  and  release  using  one  general  purpose  finite 
state  controller.  The  other  mapped  controls,  should  be  described  in  a  suitable  data  structure, 
available  from  dedicated  mapping  (Notice  1)  or  held  ICD  data  structure  (Notice  2/3)  and  passed 
as  a  parameter  to  the  generic  finite  state  controller  for  each  particular  store  type. 

11.1.7  MlL-STD-1553  Option  Restrictions  MIL-STD-1553  provides  many  optional  features. 
These  allow  significant  design  freedoms  but  reduce  the  scope  for  generic  Im^ementation  of 
hardware  and  software.  This  is  acceptable  for  general  avionics  purposes  where  a  fixed  set  of 
equipments  are  present.  MIL-STD-1760  provides  a  more  dynamic  environment  with  different 
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stores  fitted  for  different  missions.  Accordingly,  many  of  the  MIL-STD-1553  options  have  been 
restricted  (particularly  in  status  and  mode  code  usage)  and  these  restrictions  give  scope  for 
more  generic  AIS  software  implementation. 

11.1.7.1  Status  Word  Bit  Effects 

ISSUE:  What  are  the  effects  on  software  design  of  each  status  word  bit  either  having  a  specified 
use  or  not  being  permissible  to  use? 

GUIDANCE  Notice  1/2/3:  Common  status  word  bit  handling  routines  should  be  implemented  at 
the  MIL-STD-1553  level  of  software  control.  These  are  best  implemented  in  the  Bus  Controller 
firmware.  Specific  to  status  word  bit  guidance  is  included  in  paragraph  11.1.8. 

RATIONALE  Notice  1/2/3:  This  exploits  a  major  LDD  benefit  where  every  mission  store 
implements  a  status  word  bit  in  exactly  the  same  manner.  If  these  routines  are  used  at  the 
interface  level,  within  the  software  control,  then  the  software  size  requirements,  reliability  and 
verification  capability  are  all  improved. 

11.1.7.2  Mode  Coda  Effnets 

ISSUE:  What  are  the  effects  on  software  design  of  restricting  the  number  and  use  of  mode  codes? 

GUIDANCE  Notice  1/2/3;  The  mode  codes  should  be  considered  in  two  groups.  Rrst.  there  are 
the  Mode  Codes  with  associated  data,  for  example  sync  with  data  and  vector  word.  Because  these 
transfer  data,  they  must  be  managed  by  the  AIS  software  and  only  pari  processed  by  the 
MIL-STD-1553  Bus  Control  firmware.  Note  that  the  timing  use  of  synchronize  with  data  may 
force  either  logging  of  precise  time  of  generation  (Notice  1)  or  insertion  of  precise  time  (Notice 
2/3).  The  degree  to  which  the  software/firmware  for  these  nxxles  codes  can  be  generic  is 
limited.  The  second  group  are  those  mode  codes  which  have  no  associated  data  and  which  relate  to 
the  management  of  MIL-STD-1S53  data  flow.  Because  the  AIS  can  be  assured  of  their 
embodiment  in  stores,  generic  software  can  be  generated  to  effect  error  recovery.  This  software 
should  mostly  be  implemented  as  MIL-STD-1553  Bus  Control  firmware.  Specific  information 
related  to  nKKle  code  usage  is  shown  below  in  Table  11.1. 


Table  1 1.1  Mode  Code  Usages  by  AIS 


Mode  Code 

AIS  Use 

Software/Firmware 

Transmit  Status 

None 

• 

Transmitter  Shutdown 

Clear  unreliable  bus 

Software 

Override  Transmitter  Shutdown 

None 

. 

Reset  Remote  Terminal 

Firmware 

Transmit  Vector  Word 

See  11.1.8 

Software 

Synchronize  with  Data 

See  11.1.8 

Software 

Transmit  Last  Command 

None 

- 

11.1.8  Basic  Protocol  The  MIL-STD-1760  LDD  (notices)  contains  a  number  of  features 
identifiable  as  protocol.  These  are  listed  below,  together  with  the  paragraphs  of  this  Appendix 
that  address  their  impact. 
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Communication  Rules 
RT  Address 

Subaddress  restrictions 
Mode  Command  Restrictions 
Status  Word  restrictions 
Protocol  Checks 
Checksums 
Execution  Times 
Service  Request  use 
Service  Request  Servicing 
Vector  Word  demand 
Mass  Data  Transfer 
Carriage  Store  Routing 


Sections  9,10,  and  11 

11.1.3 

11.1.7.2 

11.1.8 

impacts  store  only 
11.1.4,  11.1.8.2,  and  11.1.8.10 
impacts  store  only 
11.1.8.1 
11.1.8.1 

impacts  store  only 
notice  3  only 
no  applicability 


This  section  therefore  offers  guidance  for  the  software  design  resulting  from,  the  basic  LDO 
protocol  related  to  the  use  of  the  MIL-STD-1553  vector  word  and  status  word  responses  from 
mission  stores.  These  status  word  responses  will  either  result  in,  the  scheduling  of  further 
message  transactions  to  determine  more  detail  of  the  possible  failure  and/or  the  scheduling  of 
retries  to  clear  an  error  condition.  The  service  request  bit,  subsystem  flag  bit  and  busy  bit  are 
specifically  considered. 


11.1.8.1  Vector  Word  Effects 


ISSUE;  What  are  the  effects  upon  AIS  software  design  caused  by  the  extraction  of  vector  word(s) 
after  the  raising  of  service  request  bit  by  the  mission  store? 

GUIDANCE  Notice  1 :  The  LOD  protocol  handling  software  should  clear  all  outstanding  service 
requests  via  the  vector  word  extraction  protocol.  Figure  1 1 .8  shows  a  service  request  protocol 
flow  diagram.  By  using  such  a  standard  module  Implemented  in  low  level  software  or  firmware, 
the  higher  level  processing  software  does  not  have  to  deal  with  the  scheduling  of  the  required 
acyclic  transactions.  If  the  error  condition  can  be  dealt  with  locally,  for  example  a  checksum 
failure,  then  it  should  be  cleared  and  logged  at  this  level,  again  protecting  the  calling  software. 


FIGURE  1 1 .8  Service  Request  Protocol 


RATIONALE  Notice  1 :  The  scheduling  of  the  error  determination  acyclic  transactions  and  the 
subsequent  error  recovery  acyclic  messages.  If  implemented,  at  the  application  message 
processing  level,  would  limit  the  use  of  generic  procedures  In  the  software  design.  This  Is  most 
evident  in  dealing  with  service  request  responses  for  cyclic  transmissions  running 
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asynchronously  to  the  main  acyclic  control  message  building/transmitting  software.  A  common 
low  level  routine  for  handling  extraction,  logging  and  recovery  actions  reduces  the  size  and 
increases  the  reliability  of  AIS  software. 

GUIDANCE  Notice  2/3:  The  single  vector  word  should  be  extracted  at  the  message  transmission 
software  level.  Processing  of  the  contents,  spedHed  by  the  Mission  Store’s  ICD,  should,  where 
possible,  be  handled  at  this  level. 

RATIONALE  Notice  2/3:  See  Notice  1  Rationale. 

11.1.8.2  Checksum  Failure  Recovery 

ISSUE:  What  are  the  effects  upon  AIS  software  design  in  holding  the  last  two  transmit  messages 
for  a  mission  store  to  ensure  recovery  from  a  checksum  failure? 

GUIDANCE  Notice  1 :  The  software  data  structures  for  message  transmission  processing,  require 
careful  design  such  that  an  effective  buffering  mechanism  Is  provided.  This  mechanism  can  cater 
for  holding  the  current  RX  message  and  the  previous  RX  message  for  each  Mission  Store.  This  is 
best  achieved  by  referencing  each  Mission  Store  by  its  RT  address.  Access  to  the  buffering 
mechanism  should  be  as  efficient  as  possible  as  otherwise  it  will  have  an  adverse  effect  upon  the 
intermessage  gap  time(s)  during  attempted  error  recovery.  A  possible  buffering  scheme  is 
shown  in  figure  11.9 

RATIONALE  Notice  1 :  Upon  detection  of  a  checksum  failure  (reported  via  service  request  vector 
words)  the  AIS  software  has  to  be  capable  of  retransmitting  the  message  that  product  the 
checksum  failure  and  the  message  that  yielded  the  status  word  response  (this  message  having 
been  discarded  by  the  store  because  its  service  request  bit  was  high).  It  is  important  for  the 
controlling  data  structure  to  be  able  to  provide  this  message  holding  for  all  available  RTs,  as 
other  transactions  to  other  terminals  may  havo  been  scheduled  before  the  service  request  is 
acknowledged  by  the  AIS.  Access  efficiency  is  particularly  important  for  maintaining  good 
intermessage  gap  times  during  error  recovery.  The  faster  the  error  conditions  are  cleared  the 
quicker  any  other  queued  messages  can  be  senriced. 
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FIGURE  1 1 .9  Checksum  Error  Recovery  (RX  messages) 
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GUIDANCE  Notice  2/3:  Checksum  failures  ar?  not  reported  by  the  use  of  service  requests  but  by 
polling,  as  necessary,  a  dedicated  Protocol  Status  word  in  TX  subaddress  1 1  (see  paragraph 
11.1.8.10).  There  is  therefore  no  possibility  of  restiicting  ths  message  backlog  to  two  messages 
and  no  guidance  is  given. 

11.1.8.3  Error.  Management 

ISSUE;  What  are  the  effects  on  software  design,  of  creating  a  suitable  error  management 
procedure  to  process  the  various  flags  embedded  in  the  extracted  vector  word  to  form  a  complete 
service  request? 

GUIDANCE  Notice  1  (general):  Ensure  that  the  software  is  designed  with  a  common  subroutine 
module  for  vector  woid  processing,  which  can  translate  the  flags  and  action  the  requests. 

Specific  guidance  for  each  bit  or  bit  field  is  provided  below. 

RATIONALE  Notice  1  (general):  The  benefits  of  reliability,  memory  reduction  and  the  protection 
of  upper  level  software,  from  low  level  protocol  issues,  are  gained  by  a  low  level  generic  vector 
word  translating  module. 

11.1.8.3.1  Specific  Guidance  tor  Notice  1 

GUIDANCE  Vector  Word  F2:  See  1 1.1. 8.4 

GUIDANCE  Vector  Word  F3:  Ensure  the  software  can  reschedule  a  retry  of  the  message  yielding 
the  checksum  failure  (as  in  section  11.1.8.2)  and  can  shut  down  a  store  on  successive  checksum 
failures. 

RATIONALE  Vector  Word  F3:  Upper  level  application  software  is  protected  from  recovery 
scheduling.  The  probabilities  of  two  successive  message  failures,  over  the  MIL>STD-1553  data 
bus,  are  so  remote  that  this  event  can  be  interpreted  as  a  complete  mission  store  failure. 

GUIDANCE  Vector  Word  F4:  The  upper  level  application  software  should  deal  with  a  critical 
authority  failure  by,  applying  a  safety  critical  reset  to  the  Mission  store  and  then  resequencing 
the  mission  store  to  its  current  safety  critical  state.  If  this  action  still  yields  safety  critical 
control  authority  errors,  then  the  mission  store  can  be  considered  to  be  unsafe  and  should  be 
shut  down  and  declared  ’hung'. 

RATIONALE  Vector  Word  F4;  Retries  are  necessary  to  ensure  a  functional  Mission  Store  is  not 
shut  down.  It  is  best  to  resequence  the  mission  store  through  the  safety  critical  states  to  its 
current  operational  state,  to  ensure  that  any  sequencing  failures  are  corrected.  Persistent 
critical  authority  failure  means  that,  either  there  is  a  serious  error  either  within  the  mission 
stores  checking  mechanism  or  the  aircraft's  critical  code  generation  is  not  functioning.  In  either 
case,  the  mission  store  should  be  considered  unsafe  and  should  be  shut  down. 

GUIDANCE  Vector  Word  F5:  For  operational  flight  software,  ensure  that  the  message  yielding  the 
sequencing  error  is  rescheduled.  If  a  subsequent  sequencing  failure  occurs,  ensure  the  mission 
store  is  shut  down. 

RATIONALE  Vector  Word  F5;  It  after  system  development  and  integration  have  been  cr  'npleted  a 
sequencing  error  is  flagged,  then  because  tho  correct  sequencing  would  have  been  established 
during  development  a  fault  condition  exists.  Rescneduling  the  control  message  that  yielded  the 
sequencing  error  will  allow  the  survival  of  an  intermittent  fault. 
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GUIDANCE  Vector  Word  F6:  If  there  are  rto  regular  transmissions  of  all  of  the  mission  stores 
data  set,  then  ensure  all  messages  that  contribute  to  the  mission  stores  data  set  are  retransmitted 
acyclically  as  soon  as  possible. 

RATIONALE  Vector  Word  P6:  Data  Set  consistency  should  be  maintained  and  if  the  stores  data  set 
is  not  refreshed  regularly,  the  AIS  software  should  schedule  the  retransmission  of  all  messages 
associated  with  the  data  set  as  fast  as  possible. 

GUIDANCE  Vector  Word  Codes:  Ensure  that  the  reported  missing  siQnal(s)  are  applied,  or 
reapplied,  where  possible.  Persistent  reporting  should  result  in  mission  store  shut  down. 

RATIONALE  Vector  Word  Codes:  If  the  mission  store  determines  a  signal,  or  signal  set,  which  is 
under  direct  control  of  the  AIS  software  is  hi.-ssing,  then  it  should  be  applied  or  reapplied. 

Mission  stores  should  only  be  shut  down  if  they  cannot  function  without  the  signal. 

11.1.8.3.2  Specific  Guidance  for  Notice  2/3 

GUIDANCE  Notice  2/3:  Design  the  software  to  be  capable  of  using  information  from  bits  within 
the  vector  word  (which  are  valid  if  the  format  flag  is  logic  1 ).  These  must  be  interpreted  using 
the  AIS  held  ICD  data. 

RATIONALE  Notice  2/3:  The  system  designer  has  the  freedom  to  allocate  bits  within  the  vector 
word.  The  definition  of  these  bits  is  held  within  the  ICD  which  must  be  represented  by  a  data 
structure  in  the  AIS  software.  To  reduce  tne  amount  of  software  and  allow  some  of  the  vector 
word  processing  to  be  contained  at  the  message  handling  level,  it  is  Important  to  access  the  ICD  to 
translate  the  ussd  bits  into  meaningful  software  constructs  to  be  processed  at  a  higher  level. 

11. -*.8.4  Asynchronous  Message  Scheduling 

ISSUE:  How  shoiild  the  AIS  software  implement  scheduling  of  asynchronous  message  transactions 
requested  from  a  mission  store? 

GUIDANCE  Notice  I :  The  aircraft  softvtare  must  be  capable  of  responding  to  the  request  reported 
in  a  vector  word  in  the  cases  of: 

a  A  RX  req'jest  -  Build  the  message  from  the  described  subaddress  by  calling  message 
build  routines  (refer  to  11.1.5.1)  which  use  standard  data  entities  as  described  in  the  upload 
message  description  of  the  specified  subaddress  and  then  activate  an  acyclic  transmission  of  that 
message. 


b.  A  TX  message  request  •  Schedule  an  acyclic  request  for  the  specified  subaddress  and 
Iheri  process  each  returned  data  word.  Again  using  the  message  description  taken  at  upload  to 
interpret  store  defined  message  formats.  Particular  attention  should  te  paid  to  acyclic  requests 
to  transmit  subaddress  1 1 ,  as  this  may  indicate  a  serious  store  problem. 

RATIONALE  Notice  1 :  Due  to  the  intimate  relationship  between  message  uploaded  descriptions  and 
message  building/decoding,  then  the  software  structure  must  allow  access  to  the  associated  data 
structures  from  the  vector  word  processing  module. 

GUIDANCE  Notice  2/3:  The  AIS  software  should  complete  its  current  message  processing  before 
scheduling  the  requested  transaction.  Common  message  buiiding  and  decoding  routines,  that  use 
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the  mission  stores  ICO  to  deal  with  the  request,  should  be  activated.  The  transaction  controlling 
software  shouki  ensure  that  the  requested  data  word  count  is  supplied. 

RATIONALE  Notice  2/3;  The  mission  store  has  to  hold  the  formatted  TX  subaddress  ready  even 
while  other  transaction  continues.  During  a  state  change  sequence,  it  is  better  for  the 
controlling  software  to  complete  the  current  task  rather  than  respond  instantly  to  deal  with 
asynchronous  request.  Note  that  the  Notice  3  LDD  allows  the  mission  store  to  determine  the 
asynchronous  word  count. 

11.1.8.5  Sub-svstem  Flap  Response 

ISSUE:  How  shou'd  the  AIS  software  respond  to  subsystem  flag  bit  time  17? 

GUIDANCE  Notice  1/2/3:  Ensure  that  the  subsystem  flag,  if  set,  is  valid  by  schedulirtg  a  Reset 
Terminal  Mode  code  in  response  to  the  flag.  Only  proceed  with  associated  subsystem  flag 
processing  if  the  subsequent  status  word  yields  the  subsystem  flag  again.  The  AIS  application 
software  should  attempt  to  determine  if  the  failure  is  "fatar  or  tolerable.  For  notice  1  LDD,  the 
AIS  should  extract  the  BtT  LOG  and  act  on  this  data  (see  1 1 .1 .8.6).  For  notice  2/3  LDD  the 
subsystem  flag  indicates  “total  loss  of  store  function”  and  the  store  should  therefore  be  set  as 
failed  and  all  power  and  discrete  signals  deactivated. 

RATIONALE  Notice  1/2/3:  The  aircraft  response  to  the  subsystem  flag  will  probably  result  in 
the  store  becoming  unavailable.  This  could  be  critical  to  mission  success  and  it  is  therefore  vital 
that  the  controlling  software  oniy  reacts  to  a  subsystem  flag  definitely  raised  by  the  mission 
store.  The  Reset  Terminal  Mode  code  is  the  best  method  of  ensuring  that  the  flag  has  not  been 
raised  as  a  result  of  a  temporary  mission  store  failure,  because  it  ensures  that  the  Mission  store 
RT  is  reset  by  hardware. 

11.1.8.6  Built  in  Test  Loo  (BIT  LOG)  Extraction 

ISSUE:  How  should  the  AIS  software  implement  BIT  LOG  word  extraction? 

GUIDANCE  Notice  1; 

a  Ensure  that  after  store  identification  (see  11.1.5),  the  position  of  the  BIT  LOG  word, 
data  entity  code  01 FE  is  saved  (in  terms  of  the  TX  subaddress  number  in  which  it  is  implemented 
and  the  data  word  position  within  this  message)  in  such  a  way  that  the  generic  subsystem 
handling  software  can,  if  required,  automatically  schedule  an  acyclic  request  for  the  BIT  LOG  data 
word 


b.  Following  a  confirmed  detection  that  subsystem  flag  is  set,  (see  11.1.8.5)  the  AIS 
application  software  should  extract  the  BIG  LOG  data  from  the  store 

c.  The  BIT  LOG  word  processing  should  ensure  that  the  AIS  can  respond  by,  either 
allowing  a  degraded  mission  store  operation  or  by  failing  the  store  and  automatically  selecting 
another  store  of  the  same  type  (if  one  exists  within  the  inventory).  Typical  criteria  for 
declaring  the  store  failed  are:  inability  to  extract  BIT  LOG  data  or  the  BIT  LOG  data  indicating  a 
mission  vital  function  is  unavailable,  for  example  targeting. 

d.  Where  the  BIT  LOG  indicates  an  unsafe  condition,  the  AIS  should  remove  all  power, 
declare  the  store  as  hung  and  alert  the  aircrew,  via  the  avionics  interface,  to  the  potential 
haiard.  Examples  include  store  overheating  or  critical  circuits  unsafe. 
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RATIONALE  Notice  1 :  The  Mission  store  has  the  freedom  of  positioning  the  BIT  LOG  word, 
associated  with  the  subsystem  flag  word,  in  any  data  word  position  in  any  user  definable  TX 
subaddress.  As  the  aircraft  has  to  extract  the  BIT  LOG  word  in  response  to  a  valid  subsystem  flag 
(to  determine  the  seriousness  of  the  subsystem  failure  allowing  possible  degraded  modes  or 
hanging)  then  upon  initial  upload  the  position  should  be  saved  in  some  suitable  data  structure. 
This  applies  to  each  Mission  store  implementirtg  a  BITLOG  word,  such  that  a  generic  low  level 
subsysteni  flag  handling  routine  can  extract  the  BITLOG  word.  The  upper  level  application 
software  processing  paths  should  only  have  to  respond  to  a  hung,  or  degraded  mode  state,  and  not 
the  scheduling  of  BIT  LOG  extraction. 

GUIDANCE  Notice  2/3:  None  offered,  as  subsystem  flag  is  always  translated  as  fatal  mission 
store  failure.  No  BIT  LOG  word  is  required  to  be  extracted  when  subsystem  flag  is  set  nor  is 
there  a  standard  BIT  LOG  format  provided.  It  is  possible,  that  some  store  unique  processing  could 
be  implemented. 

11.1.8.7  Busy  Bit  Management 

ISSUE:  How  should  the  AIS  implement  Busy  bit  management? 

GUIDANCE  Notice  1 :  Ensure  that  the  software  is  designed  such  that,  communication  with  a 
mission  store  during  the  known  busy  time  does  not  occur.  This  should  be  implemented  in  the 
lower  level  AIS  software/firmware  by  ensuring  that: 

a  Where  multiple  mission  stores  and  other  bus  users,  such  as  AIS  remote  equipments, 
are  receiving/transmitting  data,  then  messages  are  interleaved  and  not  grouped  *back  to  back” 
for  each  RT  address 

b.  Where  one  mission  store  dominates  the  current  bus  traffic,  then  a  minimum 
intermessage  spacing  should  be  introduced.  This  could  be  calculated  from  the  store  busy  time, 
available  from  the  store  description  (see  11.1.5).  As  this  would  be  complex  to  implement,  then 
a  basic  default  time  of  i  mS  should  be  used. 

c.  Always  use  the  maximum  busy  period  specified  (at  power  up,  Rx  message  or 
synchronize  mode  code),  rather  than  the  uploaded  times  in  the  Store  Description  Message  A.  Out 
of  specification  busy  times  should  be  interpreted  as  store  failures. 

RATIONALE  Notice  i :  Implementing  software  that  can  manage  busy  conditions  efficiently,  can  be 
difficult  and  cumbersome  as  special  buffers  have  to  be  created  and  managed  for  each  RT.  These 
problems  can  become  intolerable  in  the  AIS  where  the  terminals  change  between  missions.  The 
best  solution  is,  therefore,  to  prevent  ‘busy’  from  being  seen.  To  design  effective  software  that 
can  use  the  variable  busy  times,  uploaded  from  mission  stores,  to  maximize  data  throughput,  is 
particularly  difficult.  Timing  overheads  from  the  resultant  complexity  of  the  software  design, 
will  outweigh  the  data  throughput  benefits  offered  by  such  a  scheme. 

GUIDANCE  Notice  2/3:  Unless  the  performance  of  the  Bus  Controller  has  intermessage  gap  times 
better  than  50  microseconds,  then  it  is  suggested  that  no  special  processing  in  software  for  busy 
is  provided.  However,  provision  should  be  made  to  ensure  that  stores  are  shut  down  if 
excessively  or  permanently  busy. 

RATIONALE  Notice  2/3:  Excluding  power  up,  mission  stores  can  only  hold  the  busy  bit  high  for 
50  miaoseconds.  Even  if  the  intermessage  gap  time  is  less  than  50  us,  then  it  is  better  to 
reschedule  the  message,  potentially  yielding  the  busy  bit,  rather  than  designing  software  50  us 
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timeouts.  If  busy  persists,  then  the  software  design  should  be  capable  of  rescheduling  the 
transaction  tor  up  to  5  retries  before  failing  the  mission  store. 

11.1.8.8  Data  Bus  Error  Handling 

ISSUE:  How  should  the  AIS  manage  data  bus  errors  in  general? 

GUIDANCE  Notice  1/2/3:  The  software  designer  should  make  every  effort  to  recover  from 
errors  on  the  MIL-STD-1760  data  bus.  even  If  this  significantly  increases  the  complexity  of  the 
BC  controlling  software.  Table  1 1 .2  shows  the  general  categories  of  data  bus  errors  and 
unexpected  events  and  the  “remedies*  the  AIS  should  invoke  to  marrage  them. 

Table  11.2  Data  Bus  Errors  and  Remedies 


Error/Event 

Recovery  r '  H:hanism(s) 

Noresoonse 

Retries  and  Redundant  Bus  changeover  -  11.1.8.9 

Parity  Error 

Word  Count  Error 

Manchester  Coding 

Bit  Count 

Status  Address 

Svnc  Pattern 

Terminal  Flag 

Broadcast  Bit 

Dynamic  Bus  Control  Bit 

Reserved  Status  Bit 

Checksum  Failure  (Tx) 

Busy  Bit 

Message  retries  •  11.1.8.7 

Service  Reguest  Bit 

Transmit  Vector  Word  and  reouest  servicing  •  11.1.8.1 

Subsystem  Flag  Bit 

Reset  Mode  Code,  retries  -11.1 .8.5 

Notice  1/2/3  RATIONALE:  Mission  success  is  of  paramount  importance  and  mission  stores 
should  not  be  shut  down  unless  a  hard  failure  exists  that  prevents  any  control  of  the  mission 
store.  The  LOO  provides  protection  for  safety  critical  message  control  in  an  unreliable  data  bus 
environment.  Data  bus  errors  should  be  sufficienily  infrequent  that  relatively  lengthy  recovery 
(10  ms),  will  have  a  trivial  overall  impact  on  data  bus  loadings  and  processing  power. 

11.1.8.9  Retry  Strategy 

ISSUE:  What  Is  a  general  error  retry  scheme  for  data  bus  failures  using  primary  and  secondary 
buses? 

GUIDANCE  Notice  1/2/3:  A  software  scheme  should  be  developed  which  will  schedule  retries 
(switching  from  primary  to  secondary  data  bus  when  necessary)  organized,  and  separately 
processed,  for  each  RT.  The  error  management  scheme  should  be  unseen  by  the  controlling 
software,  which  is  only  provided  with  pass  or  fail  indication(5).  An  example  scheme  is  shown  in 
figure  11.10. 

RATIONALE  Notice  1/2/3:  Due  to  the  nature  of  RT  failures,  the  best  schente  is  to  allow 
determination  of  buses  for  each  RT,  (such  that  one  RT  might  be  r^ormally  transmitting/receivirrg 
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on  the  primary  and  another  on  the  secondary.  This  means  that  tables  have  to  be  available 
describing  each  RTs  data  bus  status.  Before  a  Mission  store  is  shut  down,  a  final  attempt  on  the 
other  channel  should  be  made,  even  if  previously  this  channel  yielded  no  response,  to  ensure  a 
hard  failure  exists.  The  application  of  three  retries  before  switching  data  bus  ensures  a  hard 
primary,  or  secondary  failure,  exists.  Mission  stores  will  have  to  be  failed  if  a  no  response  on 
both  channels  is  determined  by  the  attempted  recovery. 


FIGURE  11.10  General  Retry  Scheme 


11.1.8.10  Checksum  Failure  Recovery 

ISSUE:  How  should  the  AIS  implement  recovery  from  checksum  failure  under  notice  2/3? 

GUIDANCE  Notice  2/3:  Only  check  for  checksum  failures  on  transmitted  data  on  subaddress  1 1 
transactions. 

RATIONALE  Notice  2/3:  Checksum  failures  are  only  likely  to  be  reported  in  a  dedicated  data  word 
in  the  mission  store  monitor  message.  Safety  critical  control  will  always  result  in  the 
scheduling  of  a  mission  store  monitor  message  which  then  provides  the  protocol  check  word. 
Recovery  from  other  message  checksum  failures  might  be  initiated  by  the  mission  store 
requesting  an  asynchronous  transaction  to  the  failed  subaddress  using  service  request  (see 
11.1.8.1). 

1 1 .1 .9  Coordinate  Systems  This  section  offers  guidance  for  maximizing  the  benefits  offered  by 
the  standard  coordinate  system,  in  terms  of  software  design  and  performance. 

11.1.9.1  Size  and  Performance  Improyements 

ISSUE:  How  can  software  size  and  performance  requirements  be  improved  if  all  measurentent 
data  are  with  respect  to  standard  coordinate  systems? 
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GUIDANCE  Notice  1/2/3:  Ensure  all  calculations  to  generate  data  are,  with  respect  to  the 
available  standard  coordinate  systems,  oontaned  at  one  point  and  provide  data  readily  available 
for  mission  store  message  building. 

RATIONALE  Notice  1/2/3:  If  the  avionics  data  bus  does  not  supply  measurement  data  with 
respect  to  the  LOD  standard  coordinate  systems,  then  conversion  software  will  be  required.  If 
measurement  updates  are  being  provided  regularly,  then,  proportional  to  the  complexity  of  the 
conversion,  an  increase  in  AIS  processing  power  will  be  required.  This  situation  will  be  far 
worse  if  different  conversions  are  required  for  different  mission  stores. 

11.1.10  Entity  Definitions  This  section  offers  guidance  on  using  specific  standard  data  entity 
definitions.  The  use  of  the  safety  critical  control  and  monitor  words  has  already  been  discussed 
in  section  11.1.6. 

11.1.10.1  Benefits  of  Common  Data  Entities 

ISSUE:  How  should  the  AIS  software  be  structured  to  maximize  the  benefits  of  common  data 
entity  definitions? 

GUIDANCE  Notice  1/2/3:  As  described  in  paragraph  11.1.5,  the  AIS  should  construct  a  generic 
data  base  for  storing  all  data  entity  types.  These  data  entities  should  be  stored  in  the  standard 
LDD  form  for  entity  definition  and  data  format.  All  data  received  by  the  AIS  that  will  also  be 
processed  by  the  AIS  and  that  is  not  routed  straight  through,  should  be  recomputed  into  the 
standard  data  entity  form  as  soon  as  possible.  Obviously  where  data  is  received  in  the  correct 
form  and  hopefully  all  data  will  be,  then  no  recomputation  will  be  required. 

11.1.10.2  Discrete  Control  Management 

ISSUE:  How  should  the  AIS  Manage  the  Discrete  Control  Word  1  ? 

GUIDANCE  Notice  1 :  Ensure  that  the  different  control  fields  are  represented  in  software  in 
manageable  constructs  and  also  that,  for  using  the  control  bits,  the  sequence  of  control  changes 
resulting  are  determined  before  software  development  begins.  It  is  not  possible  to  implement  a 
generic  software  module  to  manage  this  data. 

RATIONALE  Notice  1 :  Because  there  is  ambiguity  in  the  LOD  bit  field  definition,  the  mapping  of 
control  functions  will  tend  to  be  store  unique.  More  readable  and  maintainable  software  will  be 
produced  if  bit  fields  can  be  represented  by  meaningful  constructs,  for  example  enumeration 
types. 

GUIDANCE  Notice  2/3:  None  offered  as  the  Discrete  Control  Word  standard  data  entity  has  been 
eliminated 

11.1.10.3  System  Time  Management 

ISSUE:  How  should  the  AIS  software  manage  system  time  to  ensure  synchronism  on  the 
MIL-STD-1760  interface  data  bus? 

GUIDANCE  Notice  1 :  The  AIS  low  level  Bus  Control  Software/firmware  should  latch  the  LSP  of 
system  time  into  the  system  time  update  message,  at  the  moment  of  transmission  not  the  moment 
of  queuing.  The  h^h  level  k)  low  level  task  definition  should  use  a  task  desoiptor  that  can 
indicate,  both  that  system  time  is  required  and  the  data  word  position  of  system  lime. 
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RATIONALE  Notice  1:  To  ensure  the  current  system  time  is  accurately  used  for  synchronizing  a 
Mission  Store,  the  AIS  software  must  latch  this  time  in  at  the  moment  of  transmission. 

Specifying  the  data  word  position  in  a  task  descriptor,  allows  staitdard  firmware  to  be  used  for 
latching  the  current  system  time  independent  of  where  it  is  placed  in  the  message. 

GUIDANCE  Notice  2/3:  Ensure  the  MIL-STO-1553  message  transmission  firmware  can  latch  the 
system  time  into  the  associated  data  word  for  ttie  synchronize  with  data  nxxle  code. 

RATIONALE  Notice  2/3:  All  Mission  Store  time  LSP  synchronization  can  be  achieved  with  the 
synchronize  with  data  Mode  Code.  To  ensure  the  current  system  time  is  used,  the  time  should  be 
latched  into  the  data  word  at  the  moment  of  transmission  not  the  moment  of  message  queuing. 

11.1.10.4  Usage  Qt-StQtfi.[-BlT.runfl 

ISSUE:  How  should  the  AlS  software  use  the  uploaded  Mission  Store  Interruptive  BIT  duration? 

GUIDANCE  Notice  1/2/3:  An  AIS  software  imptenr.entation  should  use  the  uploaded  interruptive 
BIT  duration  time  to  minimize  the  overall  system  IBIT  duration.  All  Mission  Stores  should 
ideally  be  placed  into  IBIT  at  the  same  time,  such  that  the  complete  Mission  Store  IBITs  are  run 
concurrently.  In  practice,  the  aircraft  available  power  wilt  limit  the  nunrtbers  of  stores  that  can 
be  simultaneously  in  IBIT.  The  AIS  application  software  can  utilize  the  IBIT  duration  data  to 
optimize  the  sequence  of  IBIT  initiation.  The  resultant  Mission  store  status  should  be  polled  by 
the  software  starting  with  the  Mission  store  with  the  earliest  IBIT  completion. 

RATIONALE  Notice  1/2/3:  An  overall  AIS  design  aim  should  be  to  reduce  the  overall  system  IBIT 
duration  to  the  minimum  period.  This  is  particularly  critical  if  IBIT  is  initiated  in  flight.  Using 
the  uploaded  IBIT  duration  time  in  the  way  described  above,  will  ensure  that  the  overall  system 
IBIT  time  is  minimize,  by  allowing  the  AIS  software  to  sort  mission  stores  into  an  IBIT  duration 
order. 

tl.t.10.5  Fuzing  Control 

ISSUE:  Control  of  Fuzing  using  the  Fuzing  Control  word. 

GUIDANCE  Notice  1/2/3:  Represent  the  fuzing  control  word  by  a  HOL  construct  and  send  the 
mission  store  default  setting  or,  if  different,  the  pilot  selection  at  the  same  time  as  the  execute 
arming  state  is  entered.  Allow  the  setting  to  be  changed  until  the  commit  state  is  entered. 

RATIONALE  Notice  1/2/3;  Mapping  the  transmission  of  this  control  word  to  the  execute  arming 
safety  critical  state  is  consistent  with  overall  safety  requirements.  Representation  of  fuzing 
option  in  HOL  constructs  aids  readability  and  maintainability. 

11.1.10.6  )i^alidily.  Word  Manaaement 

ISSUE:  How  should  the  AIS  software  manage  Validity  words? 

GUIDANCE  Notice  1/2/3:  The  AIS  has  two  areas  of  validity  flag  management.  These  are  for  data 
transmitted  to  stores  and  data  received  from  stores.  Because  there  are  residual  annuities  in 
the  LDO,  it  is  not  possible  to  fully  define  generic  modules  for  validity  management  as  the  AIS  may 
be  required  to  interface  to  differing  missipn  store  interpretations  of  validity.  Specific  guidance 
is  listed  below: 
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a  The  AIS  should  not  use  valkfity  as  ‘change*  flags  in  data  transmitted  to  stores. 

Although  this  would  potentially  allow  for  mission  store  processing  to  be  optimized  (by  only 
processing  those  data  entities  updated)  K  is  possbie  that  some  mission  stores  might  interpret  an 
invalid  flag,  referenced  to  a  key  data  entity,  as  an  indication  of  total  inability  to  function. 

b.  The  AIS  should  implement  the  vafldity  processing  for  the  mission  store  control 
message  in  such  a  manner  to  avoid,  if  at  lUI  possi>le.  indicating  any  contained  entity  as  invalid. 

c.  The  AIS  should  implement  unique  to  store  validity  modules  to  compute  the  validity 
words  for  unique  message  formats.  Entities  can  be  marked  as  invalid  under  a  number  of 
circumstances,  for  example  if  the  aircraft  source  data  is  marked  as  invalid  (and  cannot  be 
synthesized  by  s*jbstituting  an  ‘equivalent*  entity),  or  the  source  data  not  being  adequately 
u(xlaled. 

d  The  AIS  should  implement  generic  software  modules  lor  management  of  validity  data 
received  from  stores.  The  AIS  should  not  update  the  generic  data  base  (see  paragraph  1  1.1.5) 
for  entities  received  as  invalid.  Furthermore  the  latest  valk£ly  words  for  each  message  received 
by  the  AIS  should  also  be  available  to  higher  level  application  software.  This  is  effectively  using 
received  validity  flags  as  both  ‘change*  irtdicators  and  valkfity  indicators. 

11.1.10.7  Header  Code  Management 

ISSUE:  What  AIS  design  should  be  employed  in  software  management  of  Header  Codes? 

GUIDANCE  Notice  1/2/3:  All  header  codes  should  be  irxlividually  held  for  each  message  type  as 
fixed  data  and  latched  in  by  the  standard  message  building  softwWe.  These  header  codes  wiM  be 
defined  by  either  the  rwtice  l  store  description  upload  or  the  ICO. 

RATIONALE  Notice  1/2/3:  Message  header  checking  is  part  of  the  standard  protocol  checking  and 
is  required  in  every  message.  A  common  fixed  data  area  for  headers  contributes  to  the  overall 
integrity  performartce  of  an  AIS. 

11.1.11  Data  Formats  This  section  offers  guidance  for  exploitation  by  AIS  software  of  standard 
data  formats. 

11.1.11.1  Standard  Data  Word  Benefits 

ISSUE:  Can  the  benefits  of  standard  data  formats  be  realized  in  an  AIS  software  implementation? 

GUIDANCE  Notice  1/2/3:  Combirte  standard  data  word  building  modules  with  a  (^ick  access  data 
base  of  data  entities  in  the  specified  data  formats.  Access  should  be  by  the  generic  message 
building  process  discussed  in  1 1 .1 .5. 

RATIONALE  Notice  1/2/3:  The  major  benefits  of  rerkjced  software  size  and  performance 
requirements  can  be  maximized  by  bringing  together  a  data  entity  data  base  efficiently  accessed 
by  the  message  building  software. 

11-112  Base  Message  Formats  This  section  offers  GuidarKe  on  how  AIS  software  can  maximize 
the  bertefits  of  the  standard  base  message  formal. 

11.1.12.1  Base  Messaoe  Usane 

ISSUE:  How  should  the  AIS  software  use  of  base  rrtessage  formats? 
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GUIDANCE  Notice  1/2/3:  The  Standard  message  buikfing  modules  discussed  in  11.1.10.8  and 

11.1.11.1  should  be  implemented. 

RATIONALE  Notice  1/2/3:  Ger>enc  Message  buikSng  modules  are  recommended  to  exploit  the 
information  held  in  the  uploaded  store  descriptior.s/mission  store  ICD.  No  particular  guidance 
can  be  offered  as  the  most  recent  specifications  in  Notice  3  reduced  the  starxfard  message  to  )ust 
the  inclusion  of  a  header  word. 

11.1.13  Mass  Data  Transfer  This  section  offers  high  level  guidance  for  AIS  Mass  Data  Transfer 
software  implementations. 

11.1.13.1  Generic  Software  Development 

ISSUE:  Should  a  generic  mass  data  transfer  set  of  software  be  developed  in  the  AIS  or  should 
implementation  be  spedtic  to  Mission  store? 

GUIDANCE  Notice  1 :  None  offered  as  the  Mass  data  transfer  protocols  were  not  specified  within 
this  issue  of  the  standard: 

GUIDANCE  Notice  2/3:  Develop  Mass  data  transfer  handling  software.  This  should  be  specific  K> 
each  mission  store  type,  but  each  separate  implen^entation  should  have  a  common  external 
interface. 

RATIONALE  Notice  2/3:  The  complete  mass  data  transfer  protocol  is  too  complex  to  implement  a 
fuHy  generic  set  of  handling  modules  in  the  AIS.  but  a  common  interface  to  the  rest  of  the 
application  software  modules  will  improve  the  overall  software  structure. 

1 1 .2  General  Software  Issues  This  section  offers  guidance  on  the  more  general  issues  which  are 
important  to  the  software  life  cycle  of  an  AIS  implementation. 

11.2.1  Language  Selection 

ISSUE:  Which  software  language(s)  should  be  used  in  the  AIS? 

GUIDANCE:  Ail  AIS  software  should  be  impiementad  in  the  MIL-STD'ISiSA  (Ada)  HOL  with  the 
following  exceptions  listed  below.  In  either  exception  case  the  new  AIS  software  must  be 
specified  using  Ada  as  a  Program  Design  Lang*jage  (POL). 

a  Where  the  AIS  can  utilize  significant  portions  of  existing  proven  software  and  the  new 
software  will  add  less  than  30%  to  the  existing  object  code. 

b.  Where  the  software  is  pan  tioned  into  several  equipments  then  the  software  for  a 
small  equipment  may  be  written  in  an  issembly  code  or  other  convenient  language  if  tf>e  software 
function  is  definable  as  firmware  (reference  DOD-STD-2167),  or  the  software  is  not  intended 
for  end  user  support. 

RATIONALE:  The  case  for  using  Ada  is  extremely  strong.  It  is  government  policy  to  iSO  Ada  on  aH 
new  programs  where  more  than  30%  new  code  is  required.  Addilionaily,  there  are  a  number  of 
technical  reasons: 

a  Ada  is  a  ^andard  language  that  cannot  be  sU)setted. 
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b.  Each  Ada  compiler  has  tc  pass  strict  validation  tests.  This  provides  a  high  assurance 
that  the  end  user  will  be  able  to  readily  support  the  Ada  code. 

c.  The  Ada  language  addresses  all  phases  of  software  life  cycle,  offering  cost  benefits 
at  each  phase. 

d  Ada  is  a  language  designed  to  support  tiio  needs  of  real  time  embedded  systems  (the 
environment  for  AIS  software). 

e.  The  Ada  Specification  includes  advarK^  features  not  present  in  alternative  languages 
such  as  Jovial  J73  or  CMS2.  These  advanced  features  are  discussed  in  more  detail  in  section 
11.2.2,  but  include: 


-  Packages  Tasking 

•  Dynamic  Data  Structures  Exceptions 

Generics  Run  Time  constraint  checking 

•  Separate  Compilation  (present  to  a  degree  in  Jovial) 

The  cases  for  waivers  agaiust  Ada  are  usually  based  on: 


a  Historical  data  from  immature  compilers  without  Global  Optimization  or  tailored 
Run-time  Support 

b.  Compilation  of  trivial  tasks 

c.  Lack  of  state-of-the-art  target  hardware 

1 1 .2.2  The  use  of  MIL-STD-181SA  Ada  HQL  This  section  offers  guidance  for  software  design 
using  the  Ada  Programming  Language.  It  discusses  the  following  new  language  constructs,  and 
how  best  they  may  be  used  within  an  AlS  implementation: 


Packages 

Dynamic  Data  Structures 
Generic  Units 
Separate  Compilation 
Attributes 
Portability 


•  Tasking 

-  Exceptions 

•  Data  Hiding 

•  Constraint  Checking 
Data  Ab':tractions 


11-2.2.1  Ada  Packages  The  Ada  "package"  has  proved  to  be  the  principal  program  unit.  The 
package  allows  grouping  of  logically  related  entities  and  sub-programs,  which  can  then  be 
acceded  by  Software  external  to  the  package.  An  Ada  Package  consists  of  two  parts,  the  Body  and 
the  Specification.  Software  external  to  the  Package  may  be  allowed  visibility  of  the 
Specification,  but  not  the  Body.  The  inner  workings  of  the  package  are  held  within  the  body  thus 
concealing  the  cede  and  data  structures  from  external  software. 


11.2.2.1.1  Eflects  of  Package  Structure 


ISSUE:  The  effect  of  the  Ada  package  structure  upon  the  design  of  the  AIS  software. 

GUIDANCE:  It  is  advisable  to  produce  a  modular  design  where  entities  are  logically  grouped  into 
packages  with  a  min  n  .'l  set  of  package  dependertcies.  In  general,  designs  incorporating  complex 
inter-package  dependencies  are  discouraged.  This  naturally  requires  a  longer  initial  design 
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phase,  and  the  availability  of  firm  software  requirement  specifications,  before  the  task  of 
software  design  begins. 

RATIONALE:  Careful  design  of  the  modularization  into  packages,  and  the  minimization  of  package 
dependencies,  will  produce  software  that  is  easily  understock,  and  easily  modified,  without  major 
recompilatbn  (If  a  package  specification  is  modified,  then  all  packages  that  depend  upon  that 
package  must  be  re-compiled  before  executable  code  can  be  produced).  An  optimum  split  of 
logically  related  subprograms  and  data,  requires  careful  consideration  and  this  will  result  in 
longer  design  periods  than  may  have  been  historically  allocated.  This  extra  design  time  will, 
however,  result  in  a  reduction  of  total  life  cycle  costs. 

11.2.2.1.2  Packaae  Unii  Usage 


ISSUE:  The  use  of  the  package  program  units  within  the  AIS  software  design. 


GUIDANCE:  The  package  program  unit  construct  should  be  exploited  by  the  AIS  software  designer, 
because  many  LDD  requirements  can  be  a  logical  group  as  either  data  structures  or  code 
procedures/functions  (subprograms).  The  following  MIL-STD-1760  elements  could  form  the 
basis  of  principle  AIS  packages: 


Store  Descriptions 
Service  Request  Processing 
Error  Recovery 
Safety  Critical  Monitor 
Network  Management 


ICD  message  building 
Subsystem  Flag  Processing 
Safety  Critical  Control 
Standard  Entity  Processing 
Power  Switching 


RATIONALE:  Experience  of  Ada  control  systems  clearly  shows  that  logical  grouping  into  packages 
results  in  higher  modularity,  greater  reliability,  better  readability,  and  more  maintainable 
software.  In  addition,  the  LOO  lends  itself  to  this  type  of  modularization. 


11.2.2.1.3  Packaae  Development  for  Data  Only 


ISSUE:  Development  of  packages  containing  only  data 

GUIDANCE:  The  grouping  of  logical  related  data  into  packages,  should  be  used  to  develop  system 
control  data  structures  such  as  the  inventory.  However,  the  size  of  such  data  packages  should  be 
limited  to  about  200  lines. 


RATIONALE:  Access  to  data  structures  containing  System  status  information,  should  be  limited  to 
those  areas  of  the  control  software  that  require  access  to  the  data.  Package  scope  rules  fulfill 
this  requirement  and  increase  the  integrity  of  the  software.  Creating  large  data  packages, 
results  in  large  amounts  of  global  data  which  compromises  the  integrity  of  the  software  design 
solution. 


1 1 .2.2.2  Ada  Tasking  Provision  is  made  within  the  Ada  Programming  language  to  allow  the 
development  of  program  units  known  as  tasks.  Tasks  are  program  units  that  may  run 
concurrently  with  each  other,  thus  allowing  further  functional  decomposition  of  the  design.  In 
order  to  implement  ta.sking,  an  underlying  real  time  tasking  executive  is  supplied  within  the  Ada 
Run  Time  System  (RTS).  The  RTS  must  be  co  resident  with  the  application  software  In  all 
embedded  Ada  systems. 

ISSUE:  Should  tasking  be  used  in  the  AIS  software  design? 
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GUIDANCE:  Tasks  should  not  be  used  to  control  the  low  level  MIL-STO-1553  transactions  or 
LDD  protocol  handling.  If  safety  critical  and  mission  critical  software  are  separated,  then  tasks 
may  be  used  for  high  level  mission  store  control. 

RATIONALE:  Any  design  using  a  multi-tasking  environment  will  require  'task  switching'  to  take 
place,  usually  on  a  priority  basis.  The  Ada  language  makes  provision  for  this  with  the 
rendezvous.  Currently  available  Compiler/RTS  implementations  have  task  switching  overheads 
averaging  3  milliseconds,  and  never  better  than  1  ms.  As  typical  pre-launch  missile  targeting 
environments  run  in  a  20  ms  processirtg  frame,  one  task  switch  would  use  at  least  10%  of  the 
available  time,  clearly,  the  overheads  of  multiple  task  switches  would  be  unacceptable.  Where 
extra  overhead  is  of  little  consequence,  such  as  in  changing  the  operating  state  of  the  mission 
store,  then  the  powerful  design  features  offered  by  Ada  tasking  should  be  exploited.  Tasking 
should  not  be  used  for  software  embedded  in  safety  critical  controllers,  as  tasking  cannot  be 
formally  validated  and  this  would  compromise  safety  requirements. 

1 1 .2.2.3  Dynamic  Data  Structures  It  is  possible  to  design  Ada  Code  that  will  cause  complex  data 
structures  to  be  created  when  the  code  is  running.  These  data  structures  may  exist  for  only  a 
short  time.  To  support  this  language  requirement,  the  co  resident  RTS  manages  a  heap  and 
implements  a  'garbage  collector*  to  relinquish  used  heap. 

ISSUE:  Should  dynamic  data  structures  be  used  within  an  A!S  design? 

GUIDANCE:  Dynamic  data  structures  should  not  be  used  within  AIS  software. 

RATIONAL*:  Garbage  collection,  which  is  an  essential  part  of  heap  management,  generally 
involves  a  large  run-time  overhead.  This  time  overhead  is  usually  unacceptable  in  a  real-time 
system. 

1 1 .2.2.4  Exceptions  The  Ada  Programming  language  has  provision  for  dealing  with  error,  or 
exception,  events  during  program  execution.  Exceptions  may  be  raised  by  compiler  generated 
run-time  checks,  or  by  application  code.  Raising  of  an  exception  will  result  in  the  abandonment 
of  the  current  processing  path  and  the  search  for  an  in-scope  exception  handler.  If  no  exception 
handler  is  found,  then  the  co  resident  RTS  will  trap-out,  resulting  in  a  system  crash. 

ISSUE:  How  should  exceptions  be  used  within  an  AIS  software  design? 

GUIDANCE:  Exceptions  should  only  be  raised  due  to  failure  conditions  being  detected.  They  should 
never  be  used  as  a  standard  control  transfer  mechanism.  Exceptbns  should  always  be  declared 
within  a  package  specification  and  should  not  be  raised  and  handler  within  the  same  package  body. 
Exceptions  should  not  be  used  in  safety  critical  software. 

RATIONALE:  An  exception  may  be  declared  at  any  point  that  data  may  be  declared.  Assuming  that 
an  exception  declaration  is  in  scope,  then  an  exception  can  be  raised  at  any  point  within  the 
application  code  and  can  be  handled  at  nearly  any  point.  The  intended  use  of  exceptions  is  for 
error  reporting  and  use  in  other  circumstances  would  make  the  code  confusing.  Safety  analysis 
of  safety  critical  software  implementing  exceptions,  would  be  very  difficult  and  costly. 

1 1  -2.2.5  Generic  Units  The  Ada  programming  language  allows  generic  units  to  be  declared.  A 
Generic  Unit  can  be  considered  as  a  software  template  from  which  copies  can  be  taken.  The  copies 
become  specific  instances  of  the  Generic  code,  perhaps  tailored  with  parameters,  for  specific 
uses. 

ISSUE:  When  should  generic  units  be  established? 
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GUIDANCE:  Software  designed  to  support  the  LOD  will  result  in  the  establishment  of  many 
subprograms  and  packages,  which  are  general  purpose  and  win  be  required  in  any  AIS.  Once  the 
interface  to  these  packages,  that  is  the  package  specification,  has  been  fully  developed,  and 
proved,  then  they  can  be  converted  into  generic  units. 

RATIONALE:  If  immature  packages  are  used  as  generic  units,  then  the  inevitable  modifications  of 
the  packages  would  necessitate  recompilation  and  perhaps  redesign  of  any  other  units  which  use 
(instantiate)  the  modified  generic  unit. 

1 1 .2.2.6  Data  Hiding  The  Ada  language  structure  allows  the  possibility  of  hiding  data  declared 
within  a  package,  from  external  software.  Data  hiding  may  be  achieved  in  two  ways: 

ISSUE:  How  should  data  hiding  be  used  in  an  AIS  software  design? 

a  The  data  may  be  declared  within  the  body  of  the  package. 

b.  The  data  may  be  declared  as  PRIVATE  within  the  package  specification.  This  allows  the 
data  to  be  accessed  by  external  users,  but  with  the  internal  structure  hidden. 

GUIDANCE:  Data  hiding  should  be  exploited  to  the  maximum  extent  possible.  Where  practicable, 
subprograms  should  be  used  as  access  mechanisms  for  such  data. 

RATIONALE:  By  using  the  concept  of  data  hiding  to  the  full,  the  resultant  software  will  have 
greater  reliability  and  readability.  The  software  will  be  more  reliable,  because  data  that  is 
inaccessible  cannot  easily  be  accidentally  corrupted.  The  software  will  be  more  readable  because 
i.relevant  detail  will  be  hidden. 

1 1 .2.2.7  Separate  Compilations  The  Ada  programming  language  allows  each  package 
specification  and  package  body,  to  be  separately  compiled.  As  packages  communicate  via  Package 
specifications,  a  package  body  may  be  modified  and  recompiled,  without  necessitating  the  re¬ 
compilation  of  other  packages  that  are  dependent  upon  the  specification. 

ISSUE:  Use  of  the  separate  compilation  Ada  feature  to  assist  in  program  modularization. 

GUIDANCE:  The  Ada  separate  compilation  capability  should  be  exploited.  All  package 
specifications,  bodies  and  subprograms  should  be  created  as  separate  compilation  units. 

RATIONALE:  Separate  compilation  will  result  in  a  reduction  in  sortware  development  cost.  This 
is  true,  because  if  only  the  b^  needs  modifying,  then  only  the  body  needs  to  be  re-compiled.  In 
addition,  configuration  control  and  long  term  maintainability  are  enhanced  by  the  use  of  separate 
compilation. 

1 1 .2.2.B  Constraint  Checking  The  Ada  programming  language  is  a  highly  "typed*  language,  all 
data  havir.g  specified  bounds.  An  Ada  compiler  has  the  capability  of  (optionally)  producing  code 
to  perform  run-time  checks  on  all  data  accesses.  If  run  time  checks  are  enabled,  and  an  invalid 
data  access  occurs,  then  a  system  exception  will  be  raised.  If  the  exception  is  not  handled  by  the 
user  application  code,  then  the  program  will  crash  with  an  en-or  message. 

ISSUE:  When  should  full  constraint  checking  be  applied  to  object  code? 

GUIDANCE:  Constraint  checking  should  be  enabled  during  AIS  software  development,  but  should 
be  disabled  before  final  compilation  of  the  operational  software. 


254 


RATIONALE:  Run-time  checking  considerably  increases  the  object  code  size  and  run-time.  Such 
checking  is  invaluable  during  development,  but  all  constraint  error  occurrences  should  be 
eliminated  during  testing,  so  that  the  overhead  implied  by  the  checks  can  be  eliminated  in  the 
final  program. 

1 1 .2.2.9  Attributes  The  Ada  programming  language  provides  an  attribute  construct  which 
allows  attributes  of  data  items  to  be  examined.  For  example  "XYZfirsr  equates  to  the  lower 
limit  of  Item  XYZ. 

ISSUE:  Should  attributes  be  used  in  AIS  software? 

GUIDANCE:  Whenever  possible  a  data  attribute  should  be  used  rather  than  assuming  the  attribute 
is  of  a  particular  value. 

RATIONALE:  Use  of  the  attribute  facility  will  reduce  the  extent  of  software  modification  and 
retesting,  if  bounds  of  types  are  modified. 

1 1 .2.2.10  Data  Abstraction  The  extensive  range  of  predefined  types  and  user  defined  types 
combined  with  record  structures  and  multi-dimension  array  declarations  allows  the  abstraction 
of  control  design  concepts  into  powerful  flexible  data  structures  built  with  a  high  degree  of 
readability. 

ISSUE:  How  should  data  abstraction  techniques  be  applied  to  AIS  software  design? 

GUIDANCE:  The  ability  to  abstract  requirements  into  package  splits  and  control  data  structures, 
sfiould  be  taken  advantage  of. 

RATIONALE:  Use  of  data  abstraction  techniques  to  develop  the  package  split  and  data  control 
structures,  will  result  in  an  effective  and  maintainable  design. 

11.2.2.11  Portability  Software  Is  usually  designed  to  be  compiled  by  a  particular  compiler, 
and  to  run  on  a  particular  set  of  target  hardware.  It  is  often  the  case  that,  after  the  software  has 
been  completed,  it  is  necessary  to  modify  the  software  using  a  different  compiler,  or  to  use 
different  target  hardware,  or  both. 

ISSUE;  How  can  AIS  software  be  ported  to  different  targets? 

GUIDANCE:  Avoid  over  reliance  on  chapter  13  features  of  MIL-STD-1815A  and  minimize  the  use 
of  assembly  language  inserts. 

RATIONALE:  All  Ada  language  Compilers  must  implement  tfie  full  MIL-STD-1815A  requirements 
and  marketed  Ada  compilers  must  be  validate  by  passing  a  validation  suite  of  programs  witnessed 
by  a  Government  department.  The  Current  validation  suite  does  not  test  for  chapter  13 
constructs  (which  are  related  to  interfacing  with  hardware)  and  to  date  compiler  producers  have 
not  tended  tO  implement  all  of  chapter  13.  Extensive  use  of  chapter  13  constructs  will  therefore 
severely  compromise  portability.  Portability  is  also  compromised  by  excessive  use  of 
assembler  inserts  which,  by  definition,  are  target  dependent.  However,  it  may  be  necessary  to 
use  some  assembler  Inserts  for  such  things  as  unimplemented  chapter  1 3  constructs,  access  to 
special  instructions  and  where  access  speed  is  critical. 
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11.2.3  Instrudlon  Set  Archiieciures 

ISSUE:  Which  computer  Instruction  Set  Architectures  (ISA)  should  be  used  in  the  AIS7 

GUIDANCE:  No  ISA  is  specifically  recommended.  The  ISA  should  be  specified  for  AIS  processing 
(not  firmware)  by  consideration  of  existing  processors  and  new  processors. 

11.2.3.1  Existing  Processors  If  existing  processors  are  to  be  retained,  then  they  are  most 
likely  to  be  of  MIL-STD-1750,  AN/AYK-14,  Z8000  or  8080  instruction  set.  Should  more  than 
30%  of  new  software  be  required,  then  Ada  must  be  used  (see  section  1 1 .2.1).  Ada  is  not  well 
supported  for  Z8000  and  8080  targets,  so  a  new  processor  will  be  required  (see  below).  Both 
MIL-STD-1750  and  AN/AYK-14  will  be  supported  with  Ada.  and  are  therefore  suitable  for  AISs. 

1 1 .2.3.2  New  Processors  New  processors  for  the  AIS  should  be  selected  by  consideration  of 
standardization.  Ada  support,  and  processing  power;  with  standardization  being  the  most 
important  criteria  and  processing  power  the  toast. 

11.2.3.2.1  Standardization  To  improve  life  cycle  costs,  the  aircraft  designer,  or  sponsoring 
service,  may  mandate  the  use  of  a  particular  common  processing  module.  Standardization  on  a 
common  module  offers  clear  benefits  in  spares  support  and  competitive  procurement. 
Standardization  on  an  instruction  set  itself  may  offer  relative  minor  advantages,  because  only  a 
small  percentage  of  low  level  non-supportabie  code  is  likely  to  be  written  in  assembly  code. 
Currently,  government  standard  processing  modules  are 
MIL-STD-1750  or  AN/AYK-14  ISA. 

1 1 .2.3  2.2  Ada  Support  The  quality  of  Ada  support  is  related  to  such  factors  as:  the  number  of 
compiler  vendors,  the  available  tools,  and  the  efficiency  of  execution  using  the  ISA.  A  listing  of 
suitable  candidate  ISAs.  in  descending  order  of  Ada  support  availability  are: 

a  68000  (or  68020)  with  or  without  68881 

b.  8086  (or  80X861  with  or  without  co-processor 

c.  NS  32X32 

d.  MIL-STD-1750 

e.  AN/AYK  14 

f.  Z80000 

g.  Z8000 

1 1 .2.3.2.3  Processing  Power  Processing  power  is  usually  measured  by  the  speed  of  execution 
of  the  Digital  Avionics  Information  System  (DAIS)  mix  of  instructions.  This  is  rtot  always  a 
meaningful  method  of  comparing  processors,  as  it  ignores  instructions  required  to  either, 
directly  execute  complex  mathematical  functions  (SIN,  COS  square  root)  or  improve  oompitod 
code.  Examples  of  ISAs  whose  real  relative  performance  is  better  than  indicated  by  DAIS  mix, 
are  AN/AYK-14,  68020  *  68881,  and  80286  *  co-processor.  Figure  11.11  shows  a  numter 
of  comparative  processing  powers  using  the  DAIS  mix.  It  must  be  emphasized  that  specifying  an 
ISA  does  not  in  itself  specify  a  processing  performance.  The  designer  should,  however,  be  aware 
of  the  likely  performance  of  each  ISA  implementation. 

1 1 .2.3.3  Firmware  Processors  No  guidelines  are  given  here  for  positive  choice  of  firmware 
processors.  There  are  many  candidate  ISAs  available,  and  as  firmware  is  not  end-user 
supportable,  there  are  few  factors  to  consider.  Some  are  listed  below: 
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Figure  11.11  Comparative  Processing  Powers  (DAIS  mix)  with  co-processors 


a  Specifying  a  firmware  ISA  will  be  excessively  and  unnecessarily  restrictive  on  design. 

b.  ISAs  with  only  single  (military  grade)  sources  of  components  should  be  avoided. 

c.  ISAs  with  severe  limits  on  memory  capacity  should  be  avoided,  as  they  may  inhibit 
later  rTK>difications  or  reuse  of  design. 

1 1 .2.4  Processing  Requirements  This  section  discusses  the  processing  power  and  memory 
requirements  imposed  upon  an  AIS  implementing  the  LDD. 

1 1.2.4. 1  Processing  Power  Analysis  of  the  various  functional  elements  of  the  LDD  and  shows 
that  they  can  be  split  into  two  groups: 

a  Those  whose  implementation  require  considerable  lines  of  code,  but  are  only  invoked 
under  exceptional  circumstances.  These  have  little  effect  on  system  operational  processing 
power  requirements.  They  include;  Status  Word  Processing  (only  invoked  at  times  of  error) 
and  Store  Description  Processing  (only  invoked  at  Power  up). 

b.  Those  that  will  frequently  be  invoked  (kjring  high  peak  system  operation  processing, 
to  allow  control  end  re>ease  of  a  mission  store,  namely  standard  message  building  and  standard 
mes^e  decoding.  Standard  Message  processing  has  the  most  effect  upon  the  processing  power 
requirement,  as  it  will  be  invoked  on  a  regular  basis  at  the  high  peak  processing  phase  of 
targeting  a  mission  store  after  its  selection  and  prior  to  its  release.  It  should  be  noted  that 
Mission  Store  state  dianges,  using  the  safety  critical  subaddress,  do  not  have  an  effect  upon  IPS 
requirements,  as  it  is  at  these  times  that  the  peak  processing  loads  will  be  invoked  or  removed. 
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ISSUE:  What  typical  processing  power  trends  occur  from  implementing  the  LDO? 

GUIDANCE:  No  specific  IPS  figures  can  be  supplied  as  there  are  many  other  factors  effecting  AIS 
IPS  requirements.  These  factors  include: 

a  The  number  of  mission  stores  to  be  simultaneously  controlled. 

b.  The  amounts  of  data  conversion  required  for  standard  data  entities. 

c.  The  intelligence  of  the  support  hardware. 

In  general  the  implementation  of  the  LDD  can  result  in  generic  software  modules  which,  by  their 
very  nature,  have  a  processing  overhead.  The  nx>re  stores  that  are  to  be  simultaneously 
controlled,  the  less  the  IPS  are  required  compared  to  a  non  generic  solution.  This  is  shown  in 
figure  11.12. 


Selected 

FIGURE  11.12  Effects  oniFSic  'ements  of  different  software  design  strategies. 


11.2.4.2  Memory  Reouirements  ft  ir  -^'s'nentation  of  the  LCD  within  the  AIS  will  have  effects 
on  both  code  and  data  requiremerib. 

11.2.4.2.1  Coda  Memory  The  LDD  requires  the  implementation  of: 

a.  Standard  error  handling/recovery  modules 

b.  Standard  message  buiiding/decoding  modules 

c.  Standard  data  entity  word  generation  modules 
d  Standard  upload  modiles 
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ISSUE:  How  much  extra  code  memory  is  required  in  the  AIS? 

GUIDANCE:  The  amount  of  memory  is  dependent  upon  the  number  of  different  mission  store  types 
to  be  controlled.  If  one  mission  store  is  to  be  controlled,  a  25  percent  code  overhead  should  be 
used.  If  three  mission  stores  are  to  be  controlled  then  a  25  percent  reduction  should  be  used. 

11.2.4.2.2  Data  Memory  There  are  three  main  areas  where  the  LDD  impacts  AIS  memory 
requirements: 

a  Representation  of  user  definable  RX  arxl  TX  subaddresses  within  Mission  Store  data. 
Under  Notice  1  this  would  be  uploaded  from  a  mission  store.  Under  Notice  2/3  this  could  be  a 
data  structure  representation  of  the  Mission  Store's  ICO. 

b.  A  data  entity  data  base 

c.  BIT  LOG  information  built  up  from  error  conditions  reported  by  the  basic  protocols. 

ISSUE:  How  much  extra  data  memory  is  required  for  an  AIS  software  design? 

GUIDANCE:  It  is  likely  that  for  an  AIS  design  controlling  4  mission  store  types  that  20K  words 
will  be  required  to  support  the  above. 

1 1 .2.5  Software  Architectures  This  section  offers  guidance  on  how  best  to  structure  software 
for,  an  AIS  using  the  LDD.  It  does  not  discuss  the  overall  performance  requirement  of  executive 
facilities  available  for  an  AIS,  which  would  be  application  dependent,  but  assumes  that  a  multi¬ 
tasking  environment  would  be  available.  The  LOO,  as  discussed  in  section  11.1,  has  functional 
elements  which  should  be  developed  into  software  modules  capable  of  handling  the  protocol 
requirements  specified  in  the  LOD  in  an  efficient  and  general  purpose  manner.  Close  study  of  the 
LOO  requirements  show  that  the  LDD  has  three  distinct  layers  of  protocol: 

a  Upper  Layer  •  Mission  store  control,  through  the  use  of  uploaded  message 
descriptions 

b.  Intermediate  Layer  -  Mission  store  release  sequence 

c.  Basic  Layer  •  Error  Management 

This  is  analogous  to  typical  processing  layers  in  an  AIS  design  solution  using  a  MIL-STD-1553 
data  bus,  namely: 

a  Upper  Layer  -  Application  Control 

b.  intermediate  Layer  •  General  control  routines 

c.  Basic  Layer  -  MIL-STD-1553  Message  transmission 

Section  1 1 .1  also  discussed  the  need  to  contain  the  processing  to  its  layer  of  relevance,  and  to 
only  communicate  upwards  those  areas  with  which  the  processing  cannot  deal,  because  it  does  not 
have  access  to  the  required  information. 

ISSUE:  What  is  the  best  overall  software  structure  tor  an  AIS  inplementalion? 

GUIDANCE:  The  software  should  be  structured  in  strong  layers,  with; 
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a  Application  code  at  the  top 

b.  General  purpose  message  control  routines  next 

c.  Finally,  general  purpose  MIL-STO-1553  routines  that  exclusively  interface  with  the 
modules  response  for  accom^ishing  status  word  responses 

Unless  there  is  not  enough  information  at  that  level  to  perform  recovery  action,  deoodng  of 
reported  error  situations  should  be  contained  within  a  processing  layer.  Ensure  that  all 
software  responsbie  for  safely  critical  controls  are  developed  in  separate  compilation  units. 

This  may  span  several  processing  layers. 

11.2.5.1  Mapping  of  Ada  HOL  constructs  to  a  layered  approach  The  use  of  Ada  packages  and  Ada 
exceptions,  (as  discussed  in  section  11.2.2),  map  very  well  to  a  layered  approach.  An  example 
package  imi^emention  is  offered  in  figure  11.13.  The  following  rules  are  applicable: 

a  Packages  must  only  interface  with  other  packages  (and  therefore  gain  accessed  to 
their  subprograms),  if  they  are  on  the  same  layer,  or  on  the  layer  directly  below 

b.  An  Exception  must  be  handled  by  ttte  layer  on  which  it  is  raised  unless  there  is  not 
enough  information  to  handle  the  exception  at  that  layer 

This  scheme  imposes  a  slight  processing  overhead,  but  allows  the  implementation  of  the  LOD  to 
include  generic  software  modules  (see  section  11.2.2.5). 

1 1 .2.6  Reusable  Software  Reusing  software  already  developed  will,  reduce  the  cost  of 
development  for  a  new  system. 

ISSUE:  How  can  reusable  software  be  developed? 

GUIDANCE:  The  guidance  offered  in  section  11.1  is  for  the  development  of  generic  LOO  modules 
with  specified  interfaces.  Section  11.2.5  offered  guidance  in  using  these  buHdfog  components  in 
a  layered  structure.  If  this  guidance  is  followed,  then  the  resultant  software  will  be  highly 
reusable. 

11.2.7  Software  Interfaces 

ISSUE:  How  may  meaningful  software  interfaces  be  developed? 

GUIDANCE:  AIS  implementations  should  always  be  written  in  the  recomntended  HOL  Ensure  that 
all  data,  and  data  types,  have  very  meaningful  names.  Exploit  the  HOL  constructs  that  aNow  the 
structuring  of  data,  particularfy  the  record  constnict.  Always  use  comments  where  an 
implementation  is  not  obvious.  Make  extensive  use  of  the  Ada  package  cfecussed  in  section 
11.22.1,  and  data  abstraction  techniques  discussed  in  section  11.2.2.11. 

RATIONALE:  Readability  and  understandability  are  the  key  to  ntaintainability  and  therefore 
retfoced  cost  of  ownersh^. 

1 1 .2.8  PrLX^ram  Support  Environment  Software  tools  are  available  that  claim:  fanproved 
programmer  productivity,  improved  program  reliability  and  quality,  and  enhanced  long  term 
software  maintainability.  Toote  can  be  grouped  together  with  a  correlation  system  to  form  a 
program  sie>ort  environment.  Examples  of  support  tools  ve: 
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FIGURE  11.13  A  Layered  Software  Architecture 
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a  Host/Target  Symbolic  Debuggers 

b.  Syntax  sensitive  editors 

c.  Ubrary  Management  tools 

d.  Automatic  dependency  sensitive  recompilation  tools 

a  Run-time  Profiling  tools,  to  determine  time  taken  in  each  procedure,  etc 

A  support  environment  for  the  Ada  programming  language  is  called  an  Ada  Program  Support 
Environment  (APSE). 

ISSUE:  Should  a  software  support  environment  be  used? 

GUIDANCE:  An  Ada  compiler  should  be  Chosen  that  supports  an  advanced  tool  set.  The  toolset 
should  incorporate  at  least  a  Symbolic  Debugger  and  a  Ubrary  Manager.  In  addhion,  it  would  be 
wise  to  ensure  that  the  compiler  vendor  has  a  long  term  commitment  to  upgrading  and  extetKfng 
the  tool  set. 

RATIONALE:  An  AtS  software  solution  that  maximizes  the  benefits  of  a  Program  Support 
Environment,  will  reduce  the  cost  of  development  and  ownership. 

11.2.9  Software  Conffouraiion  Control  A  configuration  control  system  wiH  have  some  or  all  of 
the  following  attributes: 

a  Ensure  that  a  secure  copy  of  each  controlled  software  issue  is  kept. 

b.  Permit  only  authorized  changes  to  software. 

c.  Provide  automatic  recompilation  and  management  of  multiple  software  builds. 

d.  Allow  rebuilding  to  any  previous  release  standard. 

ISSUE:  What  type  of  configuration  oontrol  environment  should  be  used  for  control  of  AIS 
software? 

GUIDANCE:  A  computerized  configuration  management  system  should  be  chosen.  Care  should  be 
tadcen  to  ensure  that  the  system  can  interface  effectively  with  the  Ada  library  manager. 

RATIONALE:  Control  of  complex  software  build  standards  using  manual  paper  based  systems  Is 
both  excessively  time  consuming  and  prone  to  error.  Cross  referencing  is  particularly 
cumbersome.  A  computer  based  configuration  oontrol  system  will  be  fast  and  reliable,  with 
mechanisms  to  cross  reference  changes,  and  buUd  standards. 

11.3  Benefits  of  the  LDP  to  AIS  Software  The  LOD  (following  Notice  3)  contains  only  a  subset  of 
those  features  originally  envisaged  as  befog  included  in  the  stwdard.  As  a  result  the  benefits  to 
the  AIS  software  are  to  an  extent  limited.  The  foHowing  features  of  the  LOD  (to  Notice  3)  are 
those  with  the  most  potential  benefit  to  AIS  designers. 

Standard  safety  critical  formats  and  subaddresses 
Standard  data  word  and  entity  deffoitions 
Standard  coordfoato  systems 
Standard  set  of  MIL-STD-1553  options 
Standard  data  check  algorithm 
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12.  AIS  INSTALLATION  ISSUES  AND  GUIDELINES 


This  Section  considers  some  of  the  topics  relevant  to  the  installation  of  AiS  equ^xnent  in  the 
aircraft.  The  topics  covered  relate,  in  particular,  to  the  installation  and  routing  of  the  various 
types  of  cables  associated  with  the  system. 

12.1  Connectors  MIL-STD-1760  requires  the  use  of  connectors  meeting  the  intermau>bility 
requirements  of  MIL'C-38999  Series  III. 

ISSUE:  What  specific  requirement  of  MIL-C-38999  should  perhaps  be  reflected  into  other 
parts  of  the  AIS  not  controlled  by  MIL-STD-1760. 

GUIDANCE:  MIL-STD-1760  is,  of  course,  an  interface  standard  and  as  such  can  only  control  that 
wiring  associated  directly  with  the  interface,  that  is  there  is  nothing  in  the  standard  to  stop  the 
aircraft  designer  using  non-standard  connectors,  contacts,  and/or  cable  upstream  of  the  ASI. 
Such  a  change  could  be  routing  the  multiplex  data  bus  cable  through  three  separate  size  20 
contacts  instead  of  utilizing  a  twinax  contact.  It  :s  therefore  considered  imperative  that 
MIL-C-38999  Series  III  connectors  are  used  throu^ihout  the  AIS,  wherever  actual 
MIL-STD-1760  interfaces  are  being  connected,  in  order  to  maintain  the  high  degree  of  noise 
immunity  that  those  connectors  give.  Note  that  tiiis  must  include  the  overall  screen  to  be 
effective.  Note  also  that  APR  122-10  requires  the  widespread  use  of  MIL-C-38999  connectors 
throughout  any  nuclear  certified  AIS. 

12.2  Multiplex  Data  Bus  Cable  MIL-STD-1760  requires  the  use  of  twinax  contacts  across  the 
interface  and  these  in  turn  demand  the  use  of  specific  wire.  Note  that  this  demand  is  supported 
by  both  MIL-STD-1760A  and  MIL-STO-1553  which  require  cable  of  specific  base 
characteristics. 

ISSUE:  Should  specific  cable  be  used  in  the  AIS  installation? 

GUIDANCE:  It  is  not  considered  appropriate  to  utilize  different  cable  in  other  parts  of  the 
installation.  Dual  redundar)cy  is  provided  for  the  bus  so  a  high  degree  of  importartce  should  be 
given  to  physically  separating  these  cables  to  minimize  the  effects  of  battle  damage.  Note  that 
although  the  Low  Bandwidth  contact  (and  therefore  one  would  would  expect  cable)  is  identical  to 
that  for  the  Multiplex  data  bus,  the  electrical  characteristics  are  completely  different. 

12.3  Hioh  Bandwidth  Cable  The  cable  requirement  is  in  two  parts,  namely: 

a  Cable  for  the  50  ohm  contact  requirement 
b.  Cable  for  the  75  ohm  contact  requirement 

The  latter  is  controlled  by  MIL  C-39029  stash  sheets  28  and  75.  that  is  the  specifications  for 
the  mating  contacts. 

ISSUE:  Should  specific  cable  be  used  in  the  AIS  installation? 

GUIDANCE:  At  this  time  the  new  slash  sheets  (102  and  103)  for  the  50  ohm  coaxial  contacts  are 
not  yet  ptfolished.  so  no  cable  guidance  can  be  given.  However,  it  is  quite  irr^rative  that  the 
designer  realizes  that  for  High  Bandwidth  1  bist^lations,  at  toast,  coaxial  cat^  of  50  ohm 
impedance  (and  engineered  co-axial  contacts)  must  be  used  throughout  tiie  in^aUation  in  order 
that  the  VSWR  requirement  stays  within  the  speciftod  limits.  The  designer  should  also  consider 
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that  cable  compatible  with  the  above  connectors  may  have  significant  attenuation  at  the  1 .6  GHz 
type  B  signal  Emit.  Care  shouti  be  taken  to  ensure  attenuation  does  not  exceed  that  specified  in 
section  8  (MIL'STD-1760  imposes  nc  type  B  attenuation  limit). 

12.4  Release  Consent  and  Interlock  Cables  There  are  no  cable  points  to  watch  in  this  area. 
However,  it  is  recommended  that  great  care  is  taken  with  connector  layouts,  where  Release 
Consent  is  involved,  to  protect  that  signal  from  inadvertent  enabling,  for  examde  isolate  the 
contact  from  other  contacts  at  OV  potential. 

12.5  Address  Line  Cable  The  only  specific  point  to  watch  is  that  MIL-STD-1760  has  spectfc 
induced  noise  limits  and  this  will  be  important  if  cable  length  becomes  signiTicant.  for  example 
the  ASI  address  is  detailed  within  the  wing. 

12.6  Power  Cable  It  is  not  considered  api;Kopriate  to  discuss  such  requirements,  because  MIL- 
$TD-1760  has  no  particular  implementations  which  differ  from  that  presently  practiced. 
However,  it  may  be  important  to  realize  that  MtL-STO-1760  does  c?ll  out  specific  limits  of 
voltage  drop  (2  volts  for  DC  ar>d  3  volts  for  AC  applications)  under  full  load  conditions  right  up 
to  the  MSI. 


264 


13.  AIS  SYSTEM  INTEGRATION.  TESTING  AND  IN-SERVICE  SUPPORT 


This  scrtion  discusses  some  of  the  issues  relevant  to  AIS  system  integration  and  testing.  The 
extent  of  the  coverage  of  this  large  topic  >3  limited  by  the  scope  of  work  undertaken  during  the 
aAII  program 

13.1  INTEGRATION  Tt  is  paragraph  will  attempt  to  raise  some  of  the  points  which  need  to  be 
considered  when  adding  the  first  MIL-STO-1760  store  to  an  in-service  aircraft. 

13.1.1  Connectors  Tho  integration  of  any  new  store  usually  requires  the  addition  suitable 
connectors,  that  is  the  mating  half  to  that  fitted  to  the  store,  and  a  MIL-STD-1760  store  is  no 
exception.  However,  there  is  one  ma<o.'  difference  and  that,  of  course,  is  that  all  future  MIL- 
STD-1760  stores  will  then  have  already  been  catered  for 

ISSUE:  Should  the  MIL-STD-1760  connectors  be  fitted  at  the  first  available  opportunity'^ 

GUIDANCE:  Yes  of  course,  it  can  only  be  of  benefit  in  the  long  run. 

ISSUE:  Could  some  or  all  of  the  existing  connectors  be  superseded  by  the  M>L-STD-1760 
connector? 

GUIDANCE:  Providing  that  the  ^SI  carries  only  MIL-STD-1760  signals  when  a  M)L-STD-1‘^60 
store  is  fitted,  then  (he  standard  is  satisfied.  This  means  to  say  that,  with  a  suitable  umbilical 
cable(s)  adapting  the  ASI  to  the  interface  which  is  required  and  steering  devices  (relays  say) 
which  give  positive  isolation  of  signals  for  either  MIL-STD  1760  or  non-MIL-STD-1760 
stores,  an  installation  could  be  designed  to  enable  full  integration  to  take  place. 

ISSUE:  Where  should  the  ASI  be  fitted. 

GUIDANCE;  Wherever  is  convenient  for  the  ground-crew  to  attach  the  umbilical.  This  may  be  on 
the  Store  Station  Equipment,  the  pylon  side  wall  (on  a  bracket)  or  the  roof  of  the  pylon.  The 
floor  of  the  pylon  is  not  recommended,  since  the  ASI  is  a  socket  and  a  floor  installation  will 
encourage  accumulation  of  dirt  and  the  trapping  of  fluids  (water,  fuel,  hydraulic  oil  etc.). 

13.1.2  Currentiv  Installed  Wiring  It  is  expected  that  the  bulk  of  currently  installed  power 
wiring  will  be  usable  for  MIL-STO-1760A  Primary  applications.  This  is  not,  however, 
expected  to  be  the  case  for  the  Auxiliary  application,  f  Maverick  has  been,  or  is  expected  to  be, 
included  in  the  aircraft  weapon  inventory,  then  a  ^'veo  line  is  also  liable  to  be  available.  It  is 
expected  mat,  with  very  few  exceptions,  the  rest  of  the  wiring  will  require  installation. 

13.1.2.1  Power  Installation 

ISSUE:  What  28  Volt  DC  wire  will  already  be  fitted  and  will  be  usable? 

GUID.ANCE;  Sasically  each  Primary  ASI  rer^ires  four  X  26  Volts  DC  facilities,  which  have 
medium  and  light  capability  namely: 

a  2  X  26  Volts  DC  at  10  amperes  (maximum  steady  state)  to  be  used  for  28V  DC  Power 
1  and  26V  DC  Power  2 

b.  2  X  26  Volts  DC  at  100  milliamperes  (maximum  -  steady  state)  to  be  used  for 
Release  Consent  and  Interlock 
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This  installation  requires  2  X  16  AWQ  and  2  X  20  AWQ  wires  respectively  and  MIL-STD'704  is 
acceptable  in  all  four  cases.  It  is  very  likely  that  at  least  the  two  medium  capability  wires  are 
already  installed. 

ISSUE;  What  1 15V  AC  wire  will  already  be  fitted  and  be  usable? 

GUIDANCE:  It  is  believed  that  at  least  one  phase  will  probably  be  available  at  most  stations 
where  current  weapons  having  a  semi-smart  but  analog  capability  have  been  fitted,  such  as 
AIM-9  or  AGM-65. 

ISSUE:  What  initial  Auxiliary  power  capability  will  there  be? 

GUIDANCE:  It  is  unlikely  that  28V  DC  or  115V  AC  3  Phase  will  be  currently  be  installed  out  at 
pylon  stations.  Because  the  installation  requires  the  use  of  10  AWG  cable,  then  the  Auxiliary 
requirement  should  be  very  well  justified  before  commencing  or  planning  to  fit  auxiliary  power 
capability  (see  also  8.2.1.1b). 

ISSUE:  Will  Auxiliary  Interlock  be  required  and  available? 

GUIDANCE:  Auxiliary  Interlock  will,  of  course,  only  be  required  if  the  Auxiliary  itself  is  to  be 
utilized.  Because  the  Auxiliary  is  implemented  as  an  addition  to  and  not  in  lieu  of  the  Primary  it 
is  also  unlikely  that  a  fifth  28V  DC  line  will  be  available. 

13.1.2.2.  Multiplex  Data  Bus  Installation 

ISSUE:  What  airaaft  are  likely  to  have  this  installation  already  in  place? 

GUIDANCE:  In  reality,  only  those  airaaft  that  have  already  implemented  AMRAAM  and  then 
simos)  certainly  only  at  specific  stations,  for  example  fighter  aircraft  at  current  AIM-7 
stations. 

ISSUE:  Is  this  a  straight  bus  installation  using  the  classic  bus  layout  shown  in 
MIL-HDBK-1553? 

GUIDANCE;  Not  necessarily  if  battle  damage  is  to  be  minimized.  .Routing  the  bus  via  the  wingtips 
in  a  continuous  run,  leaves  the  bus  venerable  to  an  open  circuit  due  to  battle  damage  or  even  a 
straight  wire  failure.  Although  the  bus  should  be  du^  standby  redundant,  it  is  suggested  that 
other  alternatives  are  available  and  should  be  looked  at  (reference  SAE  AIR  4013).  This  issue  is 
also  considered  in  section  10. 

13.1.2.3  Multiplex  Data  Bus  Address  Installation 

ISSUE:  What  airaaft  are  likely  to  have  this  installation  already  in  place? 

GUIDANCE:  Cross  refer  to  that  given  for  the  Multiplex  Bus  in  13.1 .2.2  above. 

ISSUE:  What  part  of  the  airaaft  is  affected? 

GUIDANCE:  Sstreral  points  arise  from  this  simple  question.  Where  the  ASI  is  fitted  to  a  pylon, 
the  modification  .should  be  restricted  to  the  pylon.  Where  the  ASI  is  fitted  adjacent  to  <i  hard 
point,  then  the  modification  is  restrictsd  to  the  niicraft.  in  neither  case  are  the  connector 
contacts  to  be  ‘daisy  trained,'  this  is  illegal  because  it  requires  two  wires  in  one  contact.  Other 
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means,  such  as  module  connectors,  must  be  used.  It  may  be  necessary  to  i^vo^e  structure 
upstream  of  the  pylon  if  the  pylons  are: 

a  Not  'handed" 

b.  Interchangeable  between  stations  on  the  same  side  of  the  airaaft 
This  is  to  avoid  assignments/changes  occurring  when  pylons  are  fitted/replaced. 

13.1.2.4  Low  Bandwidth  Installation 

ISSUE:  What  aircraft  are  likely  to  have  this  installation  already  in  place? 

GUIDANCE:  The  current  wiring  typically  used  for  AIM-9  audb  does  not  meet  the 
MIL-STO-1760  requirements.  Deficiencies  are  likely  to  be  centered  on  the  need  for  a  screened 
two  wire  signal  and  the  higher  bandwidth.  Therefore,  it  must  be  assumed  that  this  will  be  a  new 
installation.  It  should  also  be  noted  that  this  is  likely  to  be  of  point  to  point  design. 

13.1.2.5  High  Bandwidth  Installation 
ISSUE:  Will  existing  cable  be  suitable? 

GUIDANCE:  The  cable  currently  fitted  is  almost  invariably  used  for  video  and  has  an  impedance  of 
between  90  and  tOO  ohms.  While  this  cable  will  orobably  be  adequate  in  the  short  term,  it  does 
not  meet  the  MIL  STD-1760  requirements  and  consideration  should  be  given  to  its  replacement, 
at  the  earliest  oppodunity,  by  the  75-ohm  cable  required  by  MIL-STD-1760.  The  50-ohm 
installation  will  be  a  new  installation  and  it  is  quite  imperative  that  this  is  implemented 
correctly.  Particular  attention  should  be  paid  to  the  use  of  suitable  contacts  in  the  aircraft 
connectors.  The  prime  reasons  for  this  are  the  1.6  GHz  and  VSWR  requirement  of 
MIL-STO-1760  which  will  be  of  prime  importance  the  first  time  a  store  with  GPS  provisions  is 
fitted. 

13.1.2.6  Interlock  Line  Installation  As  discussed  previously,  the  interlock  implementation  is 
intended  to  be  derived  from  28V  DC  using  MIL-STD-704  characteristics. 

ISSUE:  Is  interlock  a  positive  requirement? 

GUIDANCE:  Interlock  provision  is  required  by  MIL-STD-1760.  However,  neither  airc.'aft  nor 
store  are  required  to  use  it.  If  exis'ing  circuits,  power  or  otherwise,  are  being  added  to  provide 
the  interlock  requirement,  then  the  wiring  needs  routing  via  the  SMS  or  some  means  of 
communicating  'interlock  connected'  status  to  the  SMS. 

ISSUE:  Must  the  Interlock  Return  be  isolated? 

GUIDANCE:  This  is  dependent  solely  on  the  Ai.'craft  and  SMS  requirements.  Originally  the 
return  was  to  be  connected  directly  to  28V  DC  Power  1  return,  that  is  zero  volts.  However,  this 
was  modified  to  allow  the  Aircraft/SMS  to  implement  altemalive  approaches  having  considered 
the  monitor  circuit  susceptibility  to  zero  volt  noise  and  injection  of  noise  into  the  LRU. 

13. (.2.7  Release  Consent  Installation  Release  consent  is  a  safety  critical  signal  required  by  the 
standard  to  be  used  in  conjuration  with  certain  bits  of  Criticai  Control  1  word. 

ISSUE:  Are  straight  installation  rules  specified  for  this  signal? 
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GUIDANCE:  No  rules  are  specified  for  the  installation,  only  for  the  signal  parameters  across  the 
interface.  This  is  a  28V  DC  line  using  MIL-STD-704  characteristics  and  has  no  other  specified 
requirements  in  terms  of  electrical  characteristics,  even  return  is  via  28V  DC  Power  2  return. 
However,  discussions  over  the  years  have  indicated  that  when  Release  Consent  is  in  use  its 
implementation  should  be  visible.  This  breaks  down  to  'not  software  generated,  only  steered.' 
Note  that  its  initiation  shoukJ  be  via  a  Weapon  Release  button  or  Trigger,  to  keep  the  safety 
window  as  small  as  possible.  See  also  paragraph  8.2.2 .2. 

13.1.3  Electronic  Hardware  Certain  hardware  will  need  to  be  fitted  either  to  existing  black 
boxes  or  in  new  black  boxes  or  both,  namely: 

a  MIL  STO-1553  Bus  Controller 

b.  Avionic  to  SMS  Digital  Interface 

c.  Digital  Control  -  Initial  or  increased  capacity 
d  Bandwidth  switching 

e.  Power  Control  -  Initial  or  increased  capacity 

f.  InterlocK/Release  Consent  circuitry 

13.1.3.1  Bus  Controller  A  stores  management  bus.  and  therefore  an  associated  controller,  is  no 
longer  mandated  by  the  standard. 

ISSUE:  Should  a  separate  MIL  STD-1760  bus  be  installed? 

GUIDANCE:  The  safety  requirements  of  an  avionic  data  bus,  differ  vastly  from  that  of  a  data  bus 
on  which  weapons  communicate.  Within  MIL-STO-1760,  subaddresses  19  and  27  are  restricted 
to  Nuclear  Weapon  use  sniy  and  it  is  already  very  apparent  that  the  avionics  community  does  not 
authorize  such  reservations.  MiL  STD-1760  carries  a  specific  restriction  on  inadvertent 
critical  control/  authority  word  generation  over  and  abovo  any  MIL-STD-1553  requirements. 
MIL-STD-1760  typically  dictates  specific  data  formatting  for  all  the  foreseeable  Target 
Attainment*  data  entities,  which  are  only  recommended  in  MIL'HDBK-1553.  II  would  therefore 
seem  sensible,  taking  all  of  the  above  points  into  account,  to  indeed  install  a  Data  Bus  specifically 
foi  stores.  Since  none  of  the  above  considerations  would  prevent  that  bus  also  being  used  for  SMS 
purposes  then  this  could  be  a  Stores  Management  bus.  Note  that  this  would  be  a  MIL-STD-1553 
Multiplex  Data  Bus  with  certain  restriction  and  exceptions,  but  no  changes. 

13.1.3.2  Avionic  to  SMS  Digital  Interface  Much  of  the  data  to  be  received  by  MIL-STD-1760 
stores,  originates  from  Avionic  Equipment  other  than  the  SMS.  The  reverse  is  also  true,  but  to  a 
much  lesser  extent. 

ISSUE:  How  should  'Avionics  Data*  be  transferred  into  stores? 

GUIDANCE:  Although  it  is  expected  that  the  data  words  will  be  in  the  desired  format 
(MIL-STO-1760A  Notice  3  has  avoided,  wnerever  possible,  changes  to  MIL-HDBK-1553 
formats),  the  .MS  has  to  format  these  words  into  store  required  messages  carrying  such  things  as 
header,  chacksum  etc.  The  AIS  has.  therefore,  to  provide  the  requisite  Remote  Terminal(s)  to 
receive  and  transmit  data  from  the  Avionic  Bu:>  as  part  of  its  'data  service*  to  MIL-STD-1760 
stores. 

13.1.3.3  Digital  Control  Digital  control  wil'  need  to  be  modified  or  added  to  current  aircraft. 

ISSUE:  What  sort  of  modifications  are  likely  lo  be  required  on  aircraft  which  already  have  a 
digital  AIS  or  SMS  or  both? 
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GUIDANCE:  With  the  requirement  to  communicate  digitally  with  stores,  which  MIL-STD*1760 
impkmientation  means,  three  aspects  will  need  to  be  considered: 

a  Processor  capacity 

b.  Processor  sp^ 

c.  Store  capacity,  both  volatile  and  non-volatile 

In  order  to  ease  the  burden  on  the  above  topics,  consideration  iray  be  given  to  utilizing  the  Bus 
Controller  processor  to  handle  the  data  message  formatting  etc  discussed  in  paragraph  13.1.3.2. 
Indeed,  H  as  discussed  in  paragraph  13.1.3.1,  this  is  a  new  Bus  Controller,  then  oortsideration 
should  be  given  to  additionally  utilizing  it  for  the  bulk  of  data  word/message  manipulation  as 
part  of  its  management  duties. 

ISSUE:  What  sort  of  modificaiions  are  likely  to  be  required  on  aircraft  which  have  no  digital  AIS 
or  SMS? 

GUIDANCE:  The  decision  to  retrofit  these  aircraft  can  only  be  taken  in  oonjurx:tion  with  the 
decision  on  what  digital  avionics  are  to  be  fitted.  MIL-STD-1760  stores  data  is  largely  taken 
from  Avionics  equipment  and  of  course  this  has  to  be  available.  If  it  is.  then  partitioning  of  the 
MIL-STD-1760  requiremonis  between  at  least  two  processors  (say  the  Armament  Bus 
Controller  Processor  arid  the  SMS  processor)  needs  to  be  considered  very  carefully  when 
assessing  capacity,  spoed  and  store. 

13.1.3.4  Bandwidth  Switching  This  topic  covers  both  high  and  low  bandwidth  switching,  but 
discussed  together. 

ISSUE:  What  bandwidth  switching  is  likely  to  be  available  on  current  aircraft? 

GUIDANCE:  Current  requirements,  for  say  AGM'65  and  AIM-9,  will  require  aircraft  to  be  fitted 
with  a  video  line  (around  90  ohm  impedance)  and  a  wire  (sometimes  shielded)  capable  of 
carrying  a  crude  signal  in  the  audio  range.  In  order  to  connect  the  weapons  to  the  video  display 
or  intercom,  as  appropriate,  some  form  of  simple  switching  is  provided.  Consideration  should 
not  therefore  be  given  into  extending  this  facit^.  but  rather  that  a  totally  new  installation  be 
planned,  if  all  bandwidth  switching  takes  place  in  a  special  lo  type  LRU,  then  growth  can  be 
easily  provisioned  for  the  switching  and  possibly  to  extend  the  use  of  the  Low  Bandwidth 
interface  (see  MIL-STD-1760A  Note  6.9). 

13.1.3.5  Power  Control  Power  control  is  likely  to  be  affected  in  three  areas,  namely: 

a.  28V  DC  Power  1  and  Power  2  switching  requirements 

b.  115V  AC  deadfacfog 

c.  Capacity 

ISSUE:  Do  28V  DC  Power  1  and  28V  DC  Power  2  require  separate  control? 

GUIDANCE:  Yes.  MIL-STD-1760  is  quite  specific  on  the  uses  to  whic.i  oach  supply  may  be  put 
and  this  governs  the  requirement  for  separate  switching. 

ISSUE:  Why  and  when  does  the  1 1 5V  AC  require  deadfacing? 

GUiDANCE:  The  115V  AC  Supply  (aH  three  phases)  U  required  to  be  isolated  from  the  ASI 
whenever  no  store  is  physicaly  connected  to  the  ASI.  Also,  the  supply  must  be  isolated  before 
oonnector  dteoonnect  during  store  errtofoyment.  The  reason  tor  fois  requirement  is  that  the 
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connector  Dielectric  Withstanding  Voltage  requirements  cannot  otherwise  be  met  at  altitudes 
above  40,000  feet  approximately. 

ISSUE;  Is  capacity  likely  to  be  adequate? 

GUIDANCE:  Power  capacity,  as  required  by  MIL-STD-1760.  is  only  given  as  complying  with  the 
aircraft  system  specification.  Power  switching  capacity,  because  of  the  reasons  discus^ 
earlier,  is  unlikely  to  be  sufficient. 

13.1.3.6  Interlock/Release  Consent  Circuitry  Interlock  interrogation,  unlike  the  wire  and 
contact  provision,  is  an  aircraft  option  whereas  Release  Consent  is  not. 

ISSUE:  Should  interlock  interrogation  be  implemented? 

GUIDANCE;  It  is  believed  that  at  least  two  benefits  arise  from  the  ability  to  interrogate  mating  of 
the  MSI  to  the  ASI,  (or  indeed  MSI  to  CSSI  or  CSI  to  ASI),  namely: 

a  Store  electricaly  connected/disconnected 
b.  Non-critical  Store  or^  Station  detection 

Therefore  Interlock  should  indeed  be  implemented 

ISSUE:  Should  Interlock  be  used  for  deadfacing  power  to  the  connector? 

GUIDANCE;  For  the  reasons  discussed  under  13.1 .3.5,  It  is  recommended  that  this  technique  is 
terminated  as  soon  as  is  practical. 

ISSUE;  What  circuitry  is  required  for  Interlock? 

GUIDANCE;  Very  little  and  this  should  be  kept  as  close  to  the  ASI  as  possible,  if  a  data  bus  is 
available,  and  accessible,  from  pylon  to  ASI,  then  the  interlock  data  should  be  encoded  for 
transmission  on  this  bus. 

ISSUE;  What  circuitry'  is  required  for  Release  Consent? 

GUIDANCE;  As  discussed  earlier,  the  Release  Consent  implementation  should  be  made  visible. 
Therefore  it  is  considered  that  that  generation  should  be  a  switching  network  actuated  from 
either  Trigger  or  Weapon  release  and  only  steering  and/or  final  connection,  should  be  software 
controlled.  The  use  of  electro-mechanical  switches  is  recommended  as  they  also  are  easily 
visible. 

13.1 .4  Avionics  Interface  In  order  to  increase  the  chances  of  target  kill,  it  is  expected  that  all 
future  weapons  will  be  designed  with  a  MIL-STD-1 760  interface  and  will  expect  to  utilize  a 
large  quantity  of  Avionics  Data. 

ISSUE;  What  avionics  data  does  MIL-STD-1760  demand  from  the  aircraft? 

GUIDANCE;  Actually,  none.  Many  people  assume,  quite  incorrectly,  that  MIL-STD-1760  places 
a  requirement  on  the  aircraft  to  provide  the  MIL-STD-1760  Appendix  B  data  entitles.  Whereas 
in  fact  MIL  STD-1760  only  stanrtordizes  the  transfer  of  that  data  across  the  ASI  if: 

a  The  store  requires  it. 

b.  It  is  avaiiable  from  the  aircraft. 
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This  actually  means,  therefore,  that  the  situation  will  be  no  different  from  that  currently  being 
enjoyed,  in  that  the  store  will  be  fitted  to: 

a  Those  aircraft  who  have  the  avionics  equipment  to  support  its  full  mission  capability, 

b.  Those  aircraft  who  have  enough  avionics  equipnient  to  support  its  mission  and  give  it 
a  viable  capability. 

One  further  important  aspect  to  note  is  that  MIL-STD-1760  stores  should  have  the  capability  to 
provide  much  more  information  about  their  true  state  and  this  data  will  be  able  to  be  presented 
to  the  aircrew  via  the  avionics  equipment. 

13.2  Testing  This  topic  breaks  into  three  main  areas,  namely: 

a  System  Design  Verification 

b.  Aircraft  Build  Standard  Verification 

c.  Service  Testing 

13.2.1  System  Design  Verification  This  area  breaks  down  again,  into: 

a  Positive  Tests  Required 

b.  Design  Verification  by  Inspection 

c.  BC 

d.  Safety  Analysis 

13.2.1.1  Positive  Testinn 

ISSUE:  What  part(s)  of  the  MIL-STD-1760  installation  should  be  candidates  for  positive 
testing? 

GUIDANCE:  Basically  those  interfaces  which  are  networked,  namely:  the  High  Bandwidth,  Low 
Bandwidth,  and  Multi^ex  Data  Bus.  Full  integration  testing  must  be  made  on  all  three  of  these 
installations  with  particular  attention  being  paid  to  the  VSWR  requirements  of  High  Bandwidth  1 
and  also  the  MlL-STD-1553  minimum  voltage  requirements,  both  receive  and  transmit,  at  the 
ASI.  Note  that  a  similar  exercise  should  be  considered  for  the  power  installation  where,  because 
aircraft  size  dictates  long  cable  runs,  out  of  specification  voltage  drops  may  be  present. 

13.2.1.2  Verificaiion  bv  Inspection 

ISSUE:  What  part{s)  of  the  MIL-STD-1760  installation  could  be  considered  for  design 
verification? 

GUIDANCE:  Basically,  all  the  power  and  discrete  lines  fall  into  this  category,  although  some 
minor  testing,  such  as  stabilization  times,  may  be  considered. 

13.2.1.3.  EMC 

ISSUE:  What  EMC  testing,  if  any,  should  be  considered? 

GUIDANCE:  Of  prime  Importance  are  those  tests  associated  with  noise  susceptibility,  both  from 
external  to  the  MIL-STD-1760  wiring  and  also  crosstalk  internal  to  the  MIL-STD-1760 
wiring.  Although  the  other  tests  are  considered  to  be  less  irr^jortant,  they  are  not  considered  to 
be  invalid. 
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13.2.1.4  Safety  Analysis  it  i$  imperat'tve  that  a  full  safety  analysis  be  carried  out  on  any  part 
of  the  AIS  that  in  the  event  of  component  or  design  defect  has  the  capability  to: 

a  Generate  erroneous  data  onto  the  Multiplex  Data  Bus.  This  xvould  eventually  of  course 
contain  an  executable  safety  critical  command. 

b.  Erroneously  energize  Release  Consent  circuitry  whether  or  not  safety  critical  data 
are  involved. 

13.2.2  Aircraft  Build  Standard  Verification  This  is  an  aircraft  production  test  and  as  such, 
testing  can  be  limited  to  those  components  v^iich  are  not  LRUs.  Typically  these  would  be 
connectors  and  of  importance  here  would  be  the  High  Bandwidth  1  VSWR  and  MIL>STD*1553 
voltages.  Also,  stubbing  transformers,  again  for  MIL-STD-1553. 

13.2.3  Service  Testing  It  is  not  considered  necessary  to  have  in  service  test  equipment  for 
routine  testing.  However,  sophisticated  test  equipment  should  be  provided  that  will  separately 
and  fully  test  each  part  of  the  MIL-STD-1760  installatfon  and  assist  with  both  ease  and 
quickness  of  failure  location. 

13.3  Phased  MIL-STD-176Q  Implementation  Implementation  r ....  oe  phased,  but  apart  from 
one  aspect,  namely  the  high  bandwidth  networking,  this  is  of  .  j«ous  benefit.  It  is  important  to 
note  that  until  all  of  the  required  provisions  have  been  implen.cnted  the  interface  is  not 
MIL-STD-1760  but  may  have  some  limited  value. 

ISSUE:  What  part  of  the  installatior.  should  be  implemented  first? 

GUIDANCE:  All  of  the  connectors  and  wiring  (for  the  reasons  discussed  earlier),  the  muKiplex 
data  bus  electronics  (because  even  the  first  MIL-STD-1760  store  will  require  this),  and  the 
power  control  extension  (because  all  stores  use  power).  Again,  for  the  reasons  discussed 
earlier.  Release  Consent  should  also  be  installed  (albeit  only  rail  launch  stores,  such  as 
AMRAAM,  will  have  this  requiroment). 

ISSUE:  What  signals  are  left  and  when  should  they  be  installed? 

GUIDANCE:  What  is  left  is  basically  High  and  Low  Bandwidth  and,  providing  the  wiring  is 
installed  and  located  adjacent  to  the  space  earmarked  for  the  High  and  Low  Bandwidth  switching 
unit,  no  further  work  needs  doing  until  the  first  MIL-STD-1760  store  requiring  this  facility  is 
implemented. 
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14.  INDEX 


14.1  Conlent  This  section  consists  of  two  parts,  namely  an  Index  A  and  an  Index  B. 

14.1.1  Index  A  Table  14.1  contains  prime  issues,  in  alphabetical  order,  cross  referenced  to 
this  document's  paragraphs  (Appendix  A)  and  MIL'STD-1760A  paragraphs. 

14.2.2.  Index  B  Table  14.2  contains  major  subjects  from  MIL-STD*1760A,  cross  referenced 
to  this  document's  paragraphs.  These  subjects  are  in  MIL'STD-1760A  paragraph  order. 
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1.  INTRODUCTION 


1.1  Purpose  The  purpose  of  this  document  is  to  provide  further  rationale  for  the  guidance 
offered  in  sections  7  through  13  of  Appendix  A. 

1 .2  Scope  The  information  contained  herein  is  taken  from  the  experience  gained  on  the  AVS 
Implementation  and,  under  Other  Rationale,  from  urrspecified  sources  of  experience.  The  latter 
should  be  considereid  as  additional  rationale  provided  as  support  to  that  already  provided  in 
Appendix  A.  Where  information  is  supplied  under  RATIONALE,  this  is  in  addition  to  that  provided 
in  Appendix  A. 

1 .3  Document  Structure  This  document  is  structured  with  its  own  paragraph  numbering 
system,  supporting; 

a  The  paragraph  title,  which  is  a  repeat  of  that  in  Appendix  A. 

b.  A  paragraph  number,  for  example  (8.1.3],  which  is  a  repeat  of  that  in  Appendix  A  for 
the  title  and  paragra^^  under  consideration. 

c.  The  issue,  which  is  either  a  repeat  of  that  *n  Appendix  A  or  a  summary  of  that  in 
Appendix  A,  for  the  title  and  paragraph  number  under  consideration. 
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2.  RATIONALE  FOR  APPENDIX  A  SECTION  7 


Paragraphs  2.1  through  2.5  of  this  section  prov«Je  rationale  derived  from  the  AVS  and  other 
sources  to  support  the  guidance  given  in  paragraphs  7.1  through  7.5  of  Appenrfx  A.  Issue 
statements  and  subjects  have  been  summarized.  Where  rationale  was  supplied  in  the  guidance 
text,  and  further  provision  considered  superfluous,  then  extra  rationale  is  not  supplied. 

2.1  Overall  MS  Definition 

2.1.1  AIS  Definition  [7.1. 1) 

ISSUE:  AIS  Functional  Bourtdary. 

RATIONALE:  No  rationale  is  necessary  as  this  guidance  is  explanatory  material  for 
interpretation  of  section  7. 

2.1.2  Strategy  (7.1.2..7.1.3) 

ISSUE:  Should  full  MIL-STD-1760  be  required? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 


2.1.3  Integrated  Avionics  [7.1.4] 

AVS  Implementation;  The  AVS  did  not  implement  an  integrated  Avionics  style  architecture 
although  much  of  the  AVS  design  is  relevant  to  such  environments. 

RATIONALE:  The  rationale  was  provided  In  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 


2.2  Program  Objectives  |7.2| 

ISSUE:  What  program  objectives  have  to  be  defined? 

RATIONALE:  No  further  specific  rationale  is  required  as  this  section  is  a  general  discussion  of 
factors  that  require  definition  before  aetail  design  can  commence. 

2.3  Functional  Partitioning  [7.3] 


2.3.1  AIS  Incorporation  with  SMS  function  [7.3.  i] 


AVS  Implementation:  The  AVS  incorporates  many  S.^^S  functions  including  all  core  SMS  functions 
together  with  the  AIS  function.  They  include: 


Inventory  Display 
Crew  SMS  Controls 
Store  Arming 
Store  Jettison 
Power  for  Existing  Stores 


Store  Status  Display 
Store  Selection 
Store  Reiease 
Existing  Store  Targeting 
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For  each  of  these  functions  no  problems  were  encountered  with  inplementing  the  function  in  the 
AIS.  In  fact  the  collocation,  as  opposed  to  separate  implemeniation.  of  the  AIS  and  SMS  functions 
enabled  overall  reductions  in  software,  processing  power,  data  transfers  and  hardware.  The  AVS 
is  therefore  considered  to  be  representative  of  a  good  AIS  (and  SMS]  implementation. 

Other  Rattonale:  The  rationale  for  recommendmg  collocation  of  the  AIS  and  SMS  function  is  based 
on  the  following  four  considerations: 

Data  Fusion  -  Data  Security 

Common  sub-furrctions  Implementation  Difficulty 

2.3.1 .1  Data  FusiOl]  Figure  2.1  shows  a  representation  of  some  of  the  functions  and  data  content 
of  typical  AIS  and  SMS  furtctions.  Also  shown  are  the  cross  function  data  transfers  needed  to 
support  the  functions.  Clearly  a  significant  quantity  of  data  will  have  to  be  transferred  and 
should  this  be  via  a  (shared)  Avionics  data  bos  (MIL-STD-1553  or  Pl-Bus)  then  two  effects 
will  be  seen: 

a.  Data  transfer  delays  will  reduce  the  effectiveness  of  the  functions. 

b.  The  Avionics  data  bus  will  become  significantly  loaded  due  to  AIS-SMS  data  transfers. 
This  will  reduce  the  effectiveness  of  the  whole  Avionics  function. 

The  conclusion  is  that,  to  reduce  these  problems  the  AIS  and  SMS  should,  where  possible,  be  the 
same  system. 


AIS  SMS 


FIGURE  2.1  Data  Transfers  Between  AIS  &  SMS 


2.3. 1-2  Data  Security  MIL-STD-1760  requires  that  safety  critical  data  be  transferred  via  the 
ASl'MSI  interface  using  the  MIL-STD-1553  and  Release  C^sent  signals.  This  forces  the  strong 
requirement  that  these  interfaces  be  highly  secure  and  a  specific  provision  is  included  that  the 
probability  of  critical  data  demands  being  inadvertently  seen  on  the  MlL-STO-1553  bus  should 
be  less  than  i  in  100,000  hours.  This  requires  lhat  the  information  link  to  the  SMS  critical 
demands  (Arming,  Release  and  Jettison)  and  the  associated  processing  of  that  information  by  the 
AIS.  be  highly  secure.  This  is  an  extra  burden  on  the  AIS  design  but  is  a  burden  already  borne  by 
the  SMS  function.  Modem  SMS  implementations  have  these  two  characteristics;  Data  bus 
transfer  of  critical  data  demands  (Arming.  Release  etc)  and  design  for  low  probability  of 
accidents  -  typically  lass  than  1  in  10,000.000  hours.  The  conclusion  is  that  to  avoid 
unnecessary  duplication  of  the  data  security  burden  the  AIS  and  SMS  should,  where  possible,  be 
the  same  system. 

2.3. 1.3  Common  Sub-Functions  From  the  discussions  of  Data  Fusion  ar>d  Data  Security  above  it 
is  likely  that  the  designs  of  the  AIS  and  SMS  will  include  common  or  highly  similar  sub¬ 
functions.  A  few  examples  are  listed  below.  The  conclusion  is  that  most  of  these  subfunettons 
would  be  unnecessarily  duplicated  if  separate  AIS  and  SMS  systems  were  implemented  and 
therefore,  where  possible,  the  AIS  and  SMS  should  be  the  same  system. 


Sub-functions 

AIS 

SMS 

28  Volt  Critical  Signal  Switchinq 

Release  Consent 

Rre  Signals 

Power  SuDDiv  Switching 

28V.  115V 

28V.  115V 

Safely  Critical  Data  Buses 

MIL-STO-1553 

MIL-STD-1553  or  other 

Video  Signal  Switching 

HB  3 

Maverick  or  other  video 

Audio  Switching 

LB 

AIM-9  audio 

Safety  Critical  Processing 

MIL-STO'1553  Critical 
Control  message 

Arming,  Release,  and  Jettison 
dedsions 

2.3. 1.4  Implementation  Difficuttv  The  above  discussions  on  Data  Fusion,  Data  Security  and 
Common  Sub-Functions  have  addressed  the  issues  from  an  ideal  “blank  paper*  position.  The 
recommended  solution  is  shown  in  figure  2.2  as  a  combined  AIS/SMS  for  new  implementations. 
The  true  position  is  that  many  MIL  STD-1760  implementations  wiH  be  upgrades  to  aircraft 
with  possibly  only  very  basic  SMS  capabilities.  This  presents  the  problem  shown  in  figure  2.3 
where  the  AIS  upgrade  to  the  SMS  might  not  be  possible  lor  one  or  more  of  the  following 
functions; 

Analog  Network  MIL-STD-1553 

Discrete  Signals  Power  Switching/lsolation 

These  points  are  considered  in  section  9  of  Appendix  A.  It  is  dear  that  in  some  retrofit  or 
upgrade  programs  a  separate  or  partially  separate  AIS  will  be  required. 

Condusion:  Where  possible  implement  the  AIS  and  SMS  as  the  same  system. 

2.3.2  Summary  {7.3.2) 

ISSUE;  Main  allocation  of  Weapon  System  functions. 

RATIONALE;  No  further  rationale  is  necessary  as  this  included  by  detail  subjed  area  in  section 
2.4.  Paragraph  7.3.2  of  Appendix  A  is  a  summary  of  paragrsqjh  7.4.11. 
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Controls  / 


Power  Avionics  Displays 


ASI  ASI  ASI 


FIGURE  2.2  Combined  AiS/SMS  for  New  Aircraft 


2.^  Weatym  System  Paftittonino  Guidance  f7.4) 

2.4.1  Store  Interface  [7.4.1] 

2.4.1 .1  MlL-STD-lZfifl  ASti  |7.4.1.1| 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

2.4.1. 2  MIL-STD-176Q  •  MS!  [7.4.1 .2) 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  furt.her  rationale  is 
necessary. 

2.4.1. 3  Non-AEIS  Signals  [7.4.1 .3] 

AVS  Implementation:  The  AVS  implements  two  non  MIL-STO-1 760  stores.  Sidewinder  and 
MK-82  Bomb.  Substantial  oommv  nality  exists  between  signals  and  wiring  required  for  these 
stores  and  the  MIL-STD-1760  interfaces.  Extra  signals  were  required  for: 

a  Sidewiiider  Analog  Guidance  (common  wiring  with  analog  signals  of  MIL-STO-1 760) 

b.  Launcher  Manual  uncage  arxJ  1^  discretes 

c.  Nose  and  Tail  Fuze  Signals 


Substantial  commc'ality  in  data  and  decision  processing  was  achieved.  The  AVS  implementation 
appears  to  be  rep.esentative  of  a  good  aircraft  implementation. 


FIGURE  2.3  Upgrade  to  a  Basic  SMS 


Other  Rationale:  Most  existing  stores  have  powar  supply  signals  common  witft  MIL-STD>1760, 
discrete  signals  common  with  other  existing  stores  and  a  few  unique  analog  or  serial  signals. 
Data  types  (not  formats)  transferred  are  a  subset  of  data  projected  w  .v;iL-ST0-1760  stores. 
(Data  source  -  AAAS  WIDS  1-38). 

Conclusion:  Non  AEIS  signalt  should  be  inr^lemented  by  the  S. 


2.4.1. 4 


(7.4.1. 4J 


AVS  Implementation:  The  AVS  does  not  implement  suspension  equipment,  they  are  simulated  by 
the  test  system. 

Other  Rationale:  Racks  and  launchers  are  always  procured  separately  from  store  electrical 
interfacing  equipment. 

Conclusion:  Suspension  is  not  a  AIS  function 

2.4.1. 5  Post-Launch  Interfaces  (7.4.1. 5] 


AVS  Irrtplementation:  The  AVS  does  not  implement  post  launch  intertaces.  Only  one  AVS  store, 
AMRAAM,  has  a  post-launch  ^terface  arrd  this  could  not  economically  be  impl^ented  in  the  AVS. 
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Other  Rationale:  A  typical  post-launch  guided  store  is  Sparrow.  This  requires  post-launch 
radar  illumination  of  the  target.  Other  post-launch  interfaces  include  laser  guided  bombs  and 
TOW  missiles.  These  interfaces  would  be  difficult  to  implement  in  an  AIS. 

Conclusion:  Exclude  post-launch  interfaces  from  the  AIS. 

2.4.2  Store  State 

2.4 .2.1  Store  State  Change  Prompt  [7.4.2.1] 

AVS  Implementation:  Store  critical  changes  are  prompted  by  operator  action  except  where  a 
store  either  fails  or  detects  a  target.  The  prime  change  prompt  is  therefore  non-AVS  (the 
Crew). 

Other  Rationale:  Automatic  selection,  arming,  release  of  stores  is  not  generally  accepted  because 
of  safety  concerns.  However,  increased  automation  will  be  required,  particularly  in  self- 
defense  weapon  control,  in  order  to  avoid  crew  overload.  The  crew  will  still  probably  retain 
overall  control  through  ‘I  consent  to  selection.*  and  *1  consent  to  release*  switches. 

Conclusion:  Implement  State  commands  in  AIS. 

2.4.2.2  State  Command  [7 .4.2.2] 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary, 

2.4  2.3  Store  Critical  State  Monitor  (7.4.2.3j 

AVS  Implementation;  The  AVS  monitors  every  state  change  demand  to  ensure  execution  (The 
MIL-STD-1760  critical  monitor  provides  feedback  data  on  state  demanded  and  achieved).  Any 
failure  to  achieve  a  state  is  recorded  as  a  store  failure  and  failed  stores  are  deselected  from 
available  inventory.  There  must  be  doubts  as  to  how  successful  the  AVS  implementation  would  be 
in  a  real  application  with  more  simultaneous  store  state  changes,  longer  times  to  achieve  states 
and  ambiguity  in  MIL-STD-1760  interpretation.  These  doubts  do  not  invalidate  the  successful 
tight  coupling  between  store  and  aircraft  achieved  by  the  implementation.  The  MIL-STD-1760 
mutually  compatible  command  and  monitor  formats  simplify  implementation. 

Conclusion:  Implement  stale  monitor  in  AIS. 

2.4.2.4  Store  State  -  Power  SuddIv  Management  [7.4.2.4] 

AVS  Implementation;  The  AVS  determines  what  power  supplies  are  reauired  for  each  store  stale. 
Where  this  is  "incorrect*  fo:  the  store  (as  in  store  identification  where  115  volts  Is  required 
for  store  description),  the  MIL-STD-1760  service  request  protocol  is  used  to  demand  the  AVS  to 
supply  the  correct  power. 

Other  Rationale:  Aircraft  power  architectures  follow  many  varying  design  philosophies.  Some 
aircraft,  such  as  the  B1-B,  have  implemented  all  power  control  as  a  separate  aircraft 
subsystem.  This  would  bring  the  whole  power  system  into  the  AIS.  Even  in  these  cases  the  AIS 
core  would  still  be  implementing  Power  Supply  Management  for  store  states. 

Conclusion:  Implement  Store  State-Power  Supply  Management  In  AIS. 
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2.4.3  Data  to  Store 

2.4.3.1  Store  to  Store  Data  Source  [7.4.3.1] 


RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

2.4.3.2  Aircraft  Raw  Data  for  Stores  (7.4  3.2] 

AVS  Implementation:  The  AVS  receives  from  the  avionics  some  raw  data  and  part  processed  data 
for  onward  transfer  to  stores.  The  preprocessed  data  includes  data  types,  such  as  aircraft 
position,  which  have  destinations  additional  to  stores.  Unique  to  store  processing  such  as 
AMRAAM  data  fc>rmatting  and  coordinate  reconversion  is  executed  by  the  AVS  central  unit  (the 
PCE).  Processing  power  used  for  this  function  Is  minimi2ed  by  only  processing  those  data  types 
required  at  any  one  time.  This  selective  processing  would  be  difficult  to  define  for  the  avionics, 
because  the  AVS  holds  the  specific  store  state  and  data  requirements  database.  The  AVS  currently 
requires  a  large  data  rate  on  the  avionics  bus  (50%).  This  does  not  cause  a  problem  only 
because  avionics  data  bus  users  are  not  simulated.  The  data  bus  usage  could  be  improved  by 
several  methods  such  as:  configuring  avionics  8-1  traffic  to  match  mission  conditions,  reducing 
transfer  rate  of  display  data,  and  reducing  update  rate  of  target  data.  The  AVS  implementation  fias 
been  proved  to  work  successfully. 

Other  Rationale;  Raw  data  is  present  in  aircraft  systems  such  as  Radar,  INS,  and  Air  Data 
computers.  Much  of  this  data  will  be  used  in  processed  form  by  multiple  subsystems. 

Processing  into  standard  data  types  and  formats  should  only  occur  once  and.  therefore,  the  best 
location  for  the  function  is  the  processors  for  each  raw  data  system.  Firing  multiple  stores  at 
the  same  target,  or  with  the  same  aircraft  data,  will  require  the  generation  of  individual  data 
sets  for  each  store  type  and  position.  This  is  due  to  unique  formats  and  individual  store  station 
physical  alignment.  This  could  become  a  severe  burden  for  any  one  system.  The  aircraft 
complexity  can  be  partially  decoupled  from  the  number  of  stores  sele^ied/fired  by  delegating 
processing  to  the  stores  where  possible. 

Conclusion:  Raw  aircraft  data  and  data  processing  for  non-store  use  should  be  in  the  aircraft, 
not  the  AIS. 

2.4.3.3  Unique  to  Store  Data  Formatting  (7.4.3.31 

AVS  Implementation:  The  AVS  implements  unique  to  store  formatting  at  several  levels: 

a  Message  formatting  for  MIL-STD-1760  stores 

b.  Data  word  and  message  formatting  for  AMRAAM 

c.  Signal  and  data  type  formatting  for  Sidewinder 

None  of  these  subfunctions  could  be  implemented  by  the  store  and  although  they  could  be 
implemented  by  the  'avionics,'  the  avionics  processing  and  bus  load  would  increase  significantly 
when  multiple  stores  are  selected.  This  would  be  avoided  if  a  complex  and  tightly  coupled  link 
between  the  AVS  and  Avionics  is  implemented. 

Other  Rationale:  With  the  design  trend  for  integrated  processing,  the  AIS  boundary  in  data 
formritting  for  avionics  data  becomes  very  blurred. 

Conclusion:  Data  formatting  solely  for  stores  should  be  in  the  AIS. 
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2.4.3  4  Data  Recomputation  to  Store  Axes  (7.4.3.4] 


AVS  Implementation:  The  AVS  implements  recomputation  to  store  axes  in  the  following  cases: 
target  seeker  pointing  vectors  and  INS  alignment.  For  the  target  seeker  case,  the  simulated  store 
will  almost  always  have  to  convert  pointing  vector  data  to  the  specific  internal  alignment  and 
characteristics  of  the  seeker  system.  The  extra  burden  for  a  composite,  aircraft  axis  to  seeker 
axis,  alignment  would  be  minor  or  even  zero.  For  the  INS  case,  some  of  the  older  store  INS 
systems  use  mechanical  gyros  artd  this  leads  to  a  preference  for  the  store  to  define  the  axis 
system  to  minimize  computing  required  during  the  store  free  flight  phase.  This  would  require 
the  aircraft  or  AIS  to  recompute  for  store  alignment  or  guarantee  close  mechanical  alignment 
between  store  and  aircraft.  Recent  and  projected  stores  with  INS,  use  laser  gyros  with  higher 
INS  computing  power.  It  is  therefore  possible  that  the  store  can  recompute  the  data  for  the 
composite  transformation  aircraft-store  •  store  INS.  For  AMRAAM  the  store  recomputes  angle 
alignment  from  aircraft  axes  to  store  INS  axes,  but  defines  internally  a  coordinate  system 
position  near  to  the  point  of  laur)ch.  The  aircraft  or  AIS  then  has  to  recompute  target  data  to  this 
axis  system  position.  If  6  missiles  are  fired  at  one  time  the  processing  in  the  AIS  for  this 
conversion  will  be  multiplied  6  times. 

Other  Rationale:  In  an  AIS  implementation  where  most  data  processing  is  executed  centrally  (as 
in  the  AVS)  then  if  this  reformatting  were  implemented  in  the  AIS.  the  processing  power 
required  would  increase  linearly  with  the  number  of  stores  selected.  This  would  not  apply  in  a 
distributed  architecture  where  each  store  station  had  a  dedicated  processor.  Such  an 
architecture  would  have  four  significant  drawbacks: 

a.  The  processing  function  would  produce  a  delay  for  all  data  even  if  recomputation  was 
not  required.  This  delay  would  be  additional  to  the  delays  caused  by  buffering  avionics  data  to  the 
multiple  processors. 

b.  The  processing  function  would  significantly  delay  store  to  store  data  transfers  as  two 
extra  conversions  would  be  required. 

c.  The  processing  power  required  would  typically  require  at  least  a  16  bit  processor. 
This  would  add  significant  cost  and  weight  to  the  AIS. 

d.  Implementing  such  a  distributed  processing  architecture  would  significantly  degrade 
the  reliability  of  the  AIS  because  of  the  increased  number  of  complex  subfunclions. 

However,  it  is  likely  that  a  store  design,  executed  independently  from  aircraft  design,  will  tend 
to  provide  the  lowest  cost  store  design  compliant  to  MIL-STD-1760  and  this  will  probably 
require  the  AIS  to  execute  the  unique  to  store  axis  conversion. 

Conclusion:  Axes  recomputation  will  probably  be  executed  by  the  AIS. 

2.4.3.5  Interface  to  Store  (7.4.3.51 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

2.4.4  Data  from  Store  [7.4.4] 

2.4.4.1  Raw  Data  Source  [7.4.4.11 
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AVS  Implementation;  The  AVS  test  system  provided  the  simulation  of  stores.  Raw  data  such  as 
seeker  displacement  torque  is  not  simulated  per  se.  The  test  system  simulates  such  data  by 
provision  of  data  in  MIL-STD-1760  formats  at  the  MIL-STD-1760  Interface.  This  enabled  the 
AVS  to  avoid  implementaJion  of  specific  to  store  software  for  processing  store  unique  data  types 
where  these  wouid  be.  in  effect,  raw  data. 

Other  Rationale:  Many  existing  stores  do  not  process  raw  data  in  the  store,  but  provide  instead 
extremely  raw  data  at  the  interface.  Examples  include  Sidewinder  seeker  position  voltages  and 
Sparrow  tuning  sense  voltages.  These  interfaces  tend  to  derive  from  the  need  for  backwards 
'^mpatibility  of  new  missile  variants  with  the  older  versions  of  the  missiles  where  it  was  not 
possible  to  provide  signal  processing  in  the  store. 

Conclusion:  The  "data  from  store*  raw  data  source  should  clearly  be  in  the  store  and  the 
processing  of  this  data  into  MIL  STD-1760  formats  should  also  be  in  the  store. 

2.4.4.2  Unique  to  User  Formatting  (7.4.4.2) 

AVS  Implementation;  The  AVS  implements  no  store  to  store  data  communication  so  no  experience 
can  be  derived  relevant  to  a  store  as  an  end  user  of  store  sourced  data.  All  of  the  MIL-STD-1760 
stores  in  the  AVS  inventory  provide  data  which  has  the  aircraft  as  the  end  user.  In  each  case  the 
AVS  executes  no  data  reformatting  and  the  aircraft  receives  target  position  data  (as  an  example) 
in  MIL-STD-1760  formats.  This  enables  the  AVS  to  pass  data  from  stores  to  the  aircraft  with  a 
minimum  of  processing  power  used  with  maximum  of  throughput.  The  alternative 
implementation  where  the  AVS  reformatted  the  data  for  multiple  end  user  formats  would  have 
increased  the  processing  task  by  an  order  of  magnitude.  It  is  therefore  encouraged  that  all 
avionic  equipments  should  transfer  data  in  compatible  formats  with  the  reformatting  to  user 
unique  hardware  or  software  embodied  in  those  avionic  subsystems. 

Other  Rationale:  The  AVS  implementation  defined  above  may  be  difficult  to  impose  where 
standard  aircraft  ^uipments  are  in  use.  In  such  cases  it  is  likely  that  the  aircraft  data  for  the 
store  will  also  be  in  a  non  MIL-STD-1760  format  and  in  such  cases  the  AIS  should  implement  all 
of  the  reformatting.  See  also  [7 .4.3.2]. 

2.4.4.3  Becomputation  to  User  Axes  [7.4.4.3) 

AVS  Implementation:  The  AVS  stores  implement  the  recomputation  to  user  axes  in  transfer  of 
target  position  data  from  the  store  through  the  AVS  to  the  aircraft  processing  and  display 
systems.  Because  this  recomputation  is  implemented  in  the  store  two  benefits  arise: 

a  The  AVS  processing  load  is  reduced  (particularly  when  targeting  multiple  stores). 

b.  The  store  can  communicate  directly  with  other  stores  by  MIL-STD-1553  RT-RT 
transfers.  This  is  of  considerable  benefit  when  one  store  is  a  targeting  pod. 

Other  Rationale;  See  also  [7 .4.3.4]  above. 

Conclusion;  The  Axes  Recomputation  will  probably  be  executed  in  the  AIS. 

2.4.4.4  Interface  with  Avionics  17.4.4.4] 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance. 

2.4.5  Store  Selection  [7.4.5] 
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2.4.5.1  Type  Determination  [7.4.5.1] 


AVS  Implementation:  In  the  AVS,  type  determination  was  not  provided  as  an  AIS  function.  Store 
types  were  cat^orizeo  as  Bombs,  Short  Range  Air-to-Air  Missiles,  Medium  Range  Air-to-Air 
Missiles,  and  Air  to-Ground  Missiles.  Determination  of  type  select^  was  by  operator  control. 

Other  Rationale:  Store  Selection  is  usually  for  one  of  two  purposes:  threat  countermeasures  or 
offensive  action.  The  source  data  for  these  processes  is  usually  acquired  through  non  AIS 
equipment  such  as  Radar.  JTIDS,  Navigation  data.  Defensive  Aids  Systems  and  Pilot  input.  In 
tr^itional  aircraft  the  air  crew  have  been  involved  in  the  decision  loop  determining  which 
stores  to  select.  With  increased  use  of  avionics  processing  to  reduce  crew  workload  and  the 
potential  that  MIL-STD-1760  pod  stores  will  source  some  of  this  data  it  is  clearly  possible  that 
the  AIS  could  implement  store  type  determination.  However,  this  should  be  seen  as  longer  term. 

Conclusion:  The  AIS  should  not  implement  Store  Type  Determination  and  should  instead  respond 
to  preprocessed  avionic  or  crew  demands. 

2.4.5.2  Station  Determination  [7.4.52] 

AVS  Implementation:  In  the  AVS.  station  determination  was  fully  implemented  by  the  AVS 
Process  Control  Equipment.  The  algorithms  used  considered  preferred  release  patterns,  location 
of  stores  and  stores  *■  AVS  state  of  health  data  in  determining  which  locations  to  be  selected, 
armed  etc.  This  implementation  was  fully  successful  and  had  it  not  been  implemented  would  have 
placed  an  increased  load  on  the  Avionics  buses  and  either  the  crew  or  other  Avionics. 

Other  Rationale:  Station  Determination  is  now  widely  implemented  automatically  in  modern 
aircraft  SMS.  The  SMS,  if  separate  from  the  AIS.  is  therefore  the  only  other  candidate  system 
for  this  function.  Any  separation  from  the  AIS  will  increase  the  data  load  onto  the  aircraft  buses 
as  store  and  AIS  state  of  health  data  is  required  in  the  station  determination  process. 

Conclusion:  Implement  Station  Determination  in  the  AIS  unless  it  is  a  separate  system  from  the 
aircraft  SMS. 

2.4.5.3  Number  Selection  (7.4.5.3] 

AVS  Implementation:  In  the  AVS  the  number  of  stores  selected  v/as  implemented  as  a  crew  (non 
AIS)  function.  The  number  selected  can  be  incremented  or  decremented  via  the  display  system. 

Other  Rationiiie:  The  number  of  stores  selected  Is  usually  a  measure  of  the  amount  of  threat 
countermeasures  or  offensive  action  required.  For  similar  reasons  to  those  defined  in  (7.4.5. 1) 
above  the  number  of  stores  selected  will  only  be  an  AIS  function  in  the  very  long  term. 

Conclusion:  Number  Selection  is  a  non-AIS  function. 

2.4  5.4  Store  Initialization  Management  |7.4.5.4] 

AVS  Implementation:  The  AVS  fully  implements  many  store  initialization  functions.  Excluding 
inventory  determination  (see  7.4.9)  these  functions  include: 

•  Determination  and  Application  of  Normal  power 
-  Monitoring  for  state  or  state  of  health  problems 

•  AMRAAM INU  data  management 
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•  Application  of  cooling 

-  Caging/Uncaging  of  seekers 

-  System  Time  transfer  and  verification 


Implementation  of  these  functions  caused  no  problems  in  the  AVS  design.  To  have  implemented 
these  functions  in  a  separate  system  would  have  been  more  difficult  because  of  the  need  to 
transfer  excessive  data  from  the  AVS. 

Other  Rationale:  Store  initialization  functions  tend  to  be  store  specific.  Examples  of  functions 
include:  INS  alignment,  Gyro  run-up,  and  Sparrow  tuning.  \\'ith  the  continuing  trertd  for  stores 
to  be  "smart,*  both  in  function  and  internal  management,  the  burden  of  initialization 
management  placed  on  the  aircraft  will  reduce  considerably.  It  is  likely  to  reduce  to,  provision 
of  correct  data  and  power  for  the  current  store  mode  indicated  by  MIL-STD-1760  data.  The 
function  will  then  be  clearly  very  closely  linked  to  the  AIS  function. 

Cone  L'jiiun:  Implement  Store  Initialization  Management  in  the  AIS. 

2.4.5.5  Release  Package  Retention  (7.4.5.5) 

AVS  Implementation;  The  AVS  implemented  limited  retention  of  release  package  data  in  the 
Process  Control  Equipment  (PCE)  as  part  of  the  SMS  function  also  implemented.  For  bombs,  one 
package  of  data  could  be  preprogrammed  containing; 

a  Numbering  of  Bombs  to  Release 

b.  Singles,  pairs  or  Salvo  mode 

c.  Release  spacing  in  meters 

d.  Arming  mode 

e.  Arming  Time  (not  operator  variable) 

The  implementation  is  partly  unrealistic  in  that  only  one  package  per  weapon  type  is 
implemented  whereas  it  is  more  likely  that  2  or  even  3  would  be  needed  to  allow  attack  of 
alternative  targets.  In  other  respects  the  implementation  is  realistic  and  presented  no 
significant  problems  in  implementing  with  the  AIS  function.  Operator  actions  and  data  transfers, 
avionics  •  Al$,  were  reduced  during  the  critical  last  seconds  before  attack  by  implementing  the 
release  packages  in  the  AIS. 

Other  Rationale:  There  are  alternative  locations  for  release  package  retention  •  the  pilots  head 
(high  crew  load  results),  the  mission  computer  or  the  display  control  system.  The  last  two  are 
valid  candidates  for  this  function,  the  display  system  more  so  because  of  the  need  to  display  the 
pack^e  to  the  pilot  forces  a  data  transfer,  AIS  -  Display  System,  if  the  data  are  held  in  the  AIS. 
Consideration  of  requirements  such  as  updating  the  packages  as  stores  are  released  or  fail  "state 
of  health’  checks  leads  to  the  AIS  as  being  the  best  location  for  retaining  Release  Package  data. 

Conclusion:  Implement  Release  Package  retention  in  the  AIS  if  this  also  implements  the  SMS 
functions. 

2.4.6  Sioffl  Arming  [7.4.6] 

2.4.6.1  Armino/Fuzino  Mode  Determination  p.4.6.1| 

AVS  Implementation:  Only  limited  arming  mode  determination  is  possible  with  the  AVS  and  this 
is  operator  determined  (Nose  or  Tail  or  Nose  and  1ail  fuzing). 

Other  Rationale:  The  inputs  into  determining  arming  mode  include  mission  type,  store  type, 
attack  scenario  and  aircraft  parameters.  Although  this  can  be  an  automated  function  it  is 
probable  that  such  automation  will  be  limited  compared  to  preselection  by  crew. 
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Conclusion:  Arniing/Fu2ing  Mode  Determination  should  not  be  made  by  the  AIS. 

24.6.2  Arming  ImDlementation  (7.4.6.2] 

24.6.3  Armino/Fuzino  Management  [7.4.6.3) 

AVS  Implementation:  The  AVS  implemented  fuN  Arming/Fuzing  Management  as  both  AIS  and  SMS 
functions.  Operator  and  Release  Package  inputs  were  Master  Arm  and  Arming  Modes.  The  AVS 
then  executed  the  following  functions: 

a  Determined  which  stores  should  be  armed 

b.  Generated  MIL‘STD-1553  Arming  Demands  to  appropriate  MIL*STO-1760  stores 

c.  Energized  Release  Consent  to  appropriate  MIL-STD-1760  Stores 
d  Energized  correct  power  supplies  for  stores 

e.  Energized  arming  at  appropriate  S  RE 

f.  Monitored  for  correct  responses  from  stores 

Other  Rationale:  Because  of  the  formats  defined  in  MIL-STD-1760  for  arming  demand  and 
monitor  it  is  very  difficult  to  implement  arming  Management  for  MIL-STD-1760  stores  in  any 
system  other  than  the  AIS.  This  does  not  necessarily  apply  tor  existing  stores  where  arming 
management  will  be  retained  in  the  SMS  (if  a  separate  system). 

Conclusion;  Implement  Arming  Management  in  the  AIS. 

2  4.6.4  Fuzing  Times  Computation  (7.4.6  4) 

AVS  Implementation;  Only  a  very  limited  Arming  Time  function  was  implemented  in  the  AVS. 
Fixed  times  for  Arming  Time  from  Release  (50  ms)  and  Function  Time  from  Impact  (5  ms)  were 
transferred  to  the  relevant  MIL-STD-1760  store  types.  This  is  not  totally  representative  of  the 
function  required  for  all  implementations. 

Other  Rationale:  To  consider  where  best  to  implement  this  function  it  is  necessary  to  consider 
the  functions  themselves; 

Fuzing  time  from  release  Function  time  from  release 

Function  time  from  impact  Function  distance 

2.4.6.4.1  Fuzing  Tima  from  Release  This  is  the  minimum  time  that  must  expire  from  release 
before  the  fuze  and  warhead  can  be  detonated  by  impact  or  other  reason.  Note  this  is  not  the  time 
when  detonation  will  occur.  The  need  tor  such  a  time  derives  from  the  danger  that  weapons, 
after  release,  may  collide  with  each  other  or  with  the  target  while  within  lethal  range  of  the 
aircraft.  The  minimum  time  together  with  high  drag  devices  on  the  weapon  ensures  that  the 
minimum  safe  distance  is  reached  before  any  detonation  occurs.  In  older  weapons  this  function 
was  implemented  by  an  air  driven  gear  system  but  this  can  be  too  inflexible  for  effective  target 
attack  and  can  also  place  operational  limitations  on  the  attack.  Note  also  that  too  large  a  time  can 
present  problems  if  the  store  is  not  armed  before  first  impact  with  the  target.  This  Is  shown  in 
figure  2.4  where  the  desired  firing  times  are  plotted  against  aircraft  velocity  and  aircraft 
height.  Also  shown  is  the  beneficial  effect  on  allowable  attack  profiles  through  being  able  to  vary 
arming  tinw  in  real  time.  In  fact  these  diagrams  are  simplifications  arxl  do  not  allow  for  the 
effects  of  aircraft  attitude  or  store  location.  The  implication  is,  however,  real  and  ttie 
operational  effectiveness  of  the  aircraft  will  be  enhanced  If  the  arming  time  is  calculated  during 
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the  attack.  Since  the  data  tor  this  will  be  available  to  the  AIS  then  the  AIS  is  the  togicai  system  to 
implement  the  function. 


Fuzing  Time  (sec) 


Fuzing  Time  (sec) 


Must  be 
Safe 


Must  be 
Armed 


Groundspeed 


Height 


100  200  300 

Minimum  Fuzing  Times 


Height  (m) 


3  Seconds 


2  Seconds 


10  20  30  40  JC  60  70 

Maximum  Fuzing  Times 


/ 

1  Seconds  * 


Groundspeed 

(m/s) 


Allowable  Attack  Height/Speed  Zones  tor  Fuzing  Times 
FIGURE  2.4  Fuzing  Times 

ime  from  Release  This  is  the  time  at  which  the  weapon  will  detonate  even  if 


2.4.6.4.2  Function  Time  from  Release  This  is  the  time  at  which  the  weapon  will 
liTg>ad  with  the  target  has  not  occurred.  This  can  be  tor  one  of  several  reasons: 


intact. 


a  The  we^wn  contains  sensitive  data  which  would  be  of  use  to  an  enemy  if  retrieved 


b.  The  weapon  could  be  a  hazard  lo  frierxlly  forces  if  rwt  detonated  ono6  the  target  was 

missed. 


c.  The  weapon  is  required  to  detonate  at  some  future  time  but  target  impact  may  not  be 
detectable. 

The  first  two  lead  to  setting  fixed  times  for  store  types  (an  AIS  function)  but  the  last  category 
requires  crew  input  to  set  the  time. 

2.4.6.4.3  Function  Tima  from  Impact  This  is  the  time  after  sensed  impact  or  proximity  that 
detonation  will  occur.  This  can  be  for  two  reasons: 

a.  Area  Denial  -  as  in  a  mine  pattern  where  each  has  a  different  time  set.  This  will  obstruct 
mine  dearaiKto  for  the  duration  of  the  times  set.  This  time  determination  canrmt  be  an  AIS 
function. 

b.  Target  Penetration  -  by  delaying  detonation  from  intact  by  a  short  lime  more  effect  can  be 
gained  by  ensuring  detonation  inside  rather  than  on  the  target.  The  delay  time  needs  to  be 
carefully  set  and  is  a  function  of  penetration  distance,  target  'hardness.*  aircraft  velocity, 
attitude  artd  height  arxf  we^n  type.  Similar  to  arming  time  from  release,  this  is  most  effective 
if  re-calculated  up  to  the  point  of  release  and  is  therefore  best  executed  in  the  AIS. 

2.4.6.4.4  Function  Distance  This  is  the  height  or  depth  at  which  detonation  will  occur.  This 
parameter  is  effectively  a  target  position  and  cannot  be  determined  by  the  AIS. 

Conclusion:  Short  arming  times  should  be  calculated  in  the  AIS  but  lortg  time  and  distances  must 
be  determined  outside  the  AiS. 

2.4.7  StOIB.flBiflaSfl  (7.4.7] 

Much  of  the  rationale  for  this  issue  is  related  to  the  AIS/SMS  issue.  Rationale  for  this  is 
contained  referenced  to  paragraph  [7.3.1]  above,  although  some  points  are  repeated  here 

2.4.7.1  Release  Prompt  (7.4.7.11 

AVS  implementation;  In  the  AVS  the  Release  Prompt  is  by  operator  action,  for  example  operation 
of  a  Trigger  switch,  and  is  therefore  not  an  AIS  function. 

Other  Rationale:  Consent  to  initiate  release  is  a  aitical  function  and  therefore  not  able  to  b:> 
defined  by  information  available  to  an  AIS.  A  situation  where  releases  are  not  prompted  by  air 
crew  is  one  where  chaff,  flares  or  missiles  are  automatically  launched  in  response  to  detected 
threats.  This  situation  requires  prior  consent  to  release  by  the  air  crew  and  furthermore  the 
AIS  is  unlikely  to  have  sufficient  data  to  determine  release  requirements  and  would  therefore 
require  data  from  the  Defensive  Aids  Systems. 

Conclusion;  Not  an  AIS  function. 

2.4  7.2  Suspension  EQuiomeni  Management  (7.4  7.2] 

AVS  Irr^mentation:  The  AVS  implements  Suspension  Equ^ent  Management  for  MALI- 12  racks 
and  Modular  Rail  Launcrfiers  mounted  on  MAU-12  racks.  Functions  impfomented  include  Arming, 
Release  and  Monitoring.  The  in^ementation  of  these  functions  is  dosely  coi4)led  with  the 
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MIL-STO-1760  message  generation  arxl  significant  leases  in  processing  and  data  bus  loading 
MTOuld  have  occurred  had  the  functions  been  sepvated. 

Conclusion:  Suspension  Equipment  rnanagemem  should  be  implemented  by  the  AIS. 

Other  Ratiortale:  As  for  [7.3.1]  above 

2.4.7.3  Weapon  Bav  Management  (7.4.7.3) 


AVS  Implementation:  The  AVS  <Sd  not  implement  Weapon  Bay  Management  The  AVS  is 
representative  of  a  system  applied  to  an  F-16  or  F-IS  type  aircraft.  Sufficient  discrete  signals 
are  provided  at  each  station  to  implement  Weapon  Bay  Management  by  software  cf>ange. 

2.4.7.4  Separation  Management  [7.4.7.4] 

AVS  Implementation:  The  AVS  implements  full  Release  Management  induting  correct  use  and 
response  to  AEIS  signals  through  the  release  of  stores.  AiEIS  functions  Implemented  include: 


-  Analog  Network 

-  MIL-STO-1533 

-  Discrete 

-  Power 


Reconfigured  for  revised  store  loadout 

‘No  responses*  ignored  once  separation  occurs.  AH  critical  data 

generated  and  states  verified. 

Release  Consent  energized  and  de-energized  at  correct  points  and 

Interlock  monitored  to  verify  store  separation 

Correct  power  provided  during  release  and  then  ‘dead  faced*  after 

release 


Other,  Non  AEIS.  functions  implemented  include:  coordmate  system  generation  for  AMRAAM  and 
provide  coordinate  data  to  the  fire  control  computer  for  post  release  calculations;  update  of 
display  information  during  release;  and  monitoring  for  hang  ups. 


Other  Rationale:  During  release  many  functions  have  to  be  executed  in  a  short  time  frame.  Some 
of  these  are  unique  to  aircraft  and  some  unique  to  stores.  To  minimize  delays,  data  paths  should 
be  kept  short  and  therefore  Release  Management  should  be  concemrated  nearest  to  the  most 
relevant  database.  This  is  likely  to  be  in  the  AIS. 


2.4.7.S  Separation  Timing  [7.4.7.5| 


AVS  Implementation:  The  AVS  implements  a  very  simple  form  of  Separation  Timing.  Release 
spacing  demands  in  meters  are  divided  by  the  known  ground  track  velocity  to  give  Release  Timing 
in  milliseconds. 


Other  Rationale:  Accurate  release  timing  is  most  crHicai  to  ‘dumb"  un^jided  bombs.  Since  they 
have  no  terminal  guidance,  the  weapon  trajectory  and  impact  point  depc.id  solely  on  the  dynamics 
and  timing  of  the  air  vehicle  when  store  separation  occurs.  See  figurec  2.5  and  2.6.  The  relative 
importance  of  accurate  relaase  timing  has  t^n  perceived  as  reduced  in  recent  years  due  to  the 
increased  use  of  LASER  or  TV  guided  Bombs  and  the  trend  towards  stand  off  wes^wns  characterized 
by  the  projected  Modjlar  Stand  Oft  Weapon  (MSOW,  formerly  LRSOM).  Two  factors  that  win 
balance  against  this  are: 

a  The  relative  vuinerabiHiy  of  aircraft  involved  in  LASER  or  TV  girided  bomb  release 
compared  to  tiind*  release  of  <kmib  bombs  at  high  velocity  and  low  latitude  with  release  potait 
determined  by  use  of  predsior'  INS,  TERCOM  or  GPS  mechanisms. 
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FIGURE  2.6  Weapon  Dynamics 
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b.  The  high  o^t  of  protracted  combat  wili  lead  to  dumb  weapons  being  used  as  foNow  up 
to  targets  softened  by  use  of  ‘stand  ofT  weapons. 

In  implementing  the  release  timing  function  there  are  five  key  inputs: 

a  The  target  position  and  velocity  which  is  provided  by  an  akcraft  sensor,  crew, 
briefing  system,  or  JTIDS. 

b.  The  aircraft  dynamics  (velocity,  position,  altitude)  available  from  the  aircraft 
navigation  system. 

c.  The  aircraft  air  dynamics  (air  velocities,  angle  of  attack  etc)  which  is  available  from 
the  air  data  computer. 

dL  The  weapon  ballistics  data  (mass,  drag,  lift  etc.). 

&  The  weapon  station  characteristics  (store  downforce,  local  airflow  effects,  angle  of 
S&RE  etc.). 

There  are  also  two  key  outputs: 

a  Release  timirtg  to  SMS  function  (posstoly  collocated  with  AIS). 

b.  Aircraft  trajectory  (steering  commands  to  the  HUD  or  the  flight  control  system  to 
ensure  the  aircraft  is  capable  of  releasing  stores  to  hit  the  target). 

Traditionally  this  function  has  been  implemented  in  the  Rre  Control  Computer  or  Mission 
Computer  and  Inaccuracies  have  resulted  due  to  weapon  station  unique  characteristics  not  being 
consideted.  From  a  data  path  viewpoint  and  considering  the  above  iriputs  and  outputs  the  AIS  is 
the  best  location  for  the  function. 

Conclusion:  Implement  Separation  Timino  determination  to  the  AIS. 

2.4.7.6  Impact  Point  Determination  [7.4.7.6) 

AVS  Implementation:  in  the  AVS  the  impact  points  are  recced  as  avionic  data  (target  positions) 
or  crew  inputs  (bomb  drop  points).  Impact  point  determination  is  therefore  not  implemented  as 
an  AIS  function. 

Other  Rationale:  Impact  points  are  target  positions  and  cannot  be  readSy  detem^ed  by  the  AIS. 
Conclusion:  Not  an  AIS  function. 

2.4.7.7  Separation  Sequence  Determination  [7.4.7.7] 

AVS  Implementation:  The  AVS  to  implementing  w  SMS  function  also  totplemented  the  Release 
Sequence  Determination  function.  An  algorithm  for  selecting  the  'nexT  release  was  deltoed 
giving  regard  to: 

a  Av^lbbte  stores  of  the  correct  type 

b.  Aircraft  balance  consideraticns  (see  {7.4.7.9]) 

c.  Preference  to  release  outer  stores 

d  Preference  to  stores  on  toe  Port  side 
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The  most  difficult  (>art  of  implementing  this  function  is  during  fast  releases  of  "dumb*  bombs 
where  the  next  release  cannot  be  determined  until  the  success  or  hung  state  of  the  previous 
release  can  be  verified.  Thus,  care  had  to  be  taken  to  ensure  the  algorithm  did  not  take  too  long 
and  ensure  the  algorithm  was  executed  inside  the  tinging  loop. 

Other  Rationale;  Release  sequences  can  be  extremely  complex  due  to  the  highly  complex 
aerodynamic  interactions  between  captive  and  released  stores.  This  leads  frequently  to 
individual  sequences  being  defined  for  aircraft  types,  weapon  types  and  even  specific  loadouts. 
Such  definitions  of  function  are  clearly  related  to  the  SMS  function. 

Conclusion:  Only  an  AiS  function  if  implemented  with  the  SMS. 

2.4.7.8  Hang  Up  Detection  (7.4.7.81 

AVS  Implementation:  In  the  A  VS  stores  can  be  declared  "hung,*  that  is  unusable  but  retained  for  a 
number  of  reasons  including; 

a  Failure  of  MIL-STD-1760  communication. 

b.  Failure  to  achieve  demanded  MIL  STD-1760  critical  states. 

c.  Mismatch  of  inventory  data  or  power  up  inventory  determination. 

d.  Detected  failure  of  store  to  separate  when  release  or  jettison  demanded  (detected  by 
total  failure  of  MIL-STD-1760  interlock  and  MAU-12  WRIS  inputs  to  change  within 
predetermined  time). 

This  function  required  a  fusion  of  MIL-STD-1760  data  (Interlock,  MIL-STD-1553)  and  SMS 
data  (MAU-12  WRIS)  and  a  combination  of  sub-functions.  To  have  implemented  these  as  a 
separate  AIS  and  SMS  function  would  have  increased  processing  loads  and  degraded  performance. 

Other  Rationale:  The  AVS  implementation  is  typical  of  that  required  in  other  implementations. 

If  a  store  is  either  too  readily  or  too  slowly  declared  hung,  operational  performance  can  be 
inhibited.  To  separate  the  function  into  separate  AIS  and  SMS  systems  would  tend  to  degrade  the 
determination  accuracy  either,  because  of  less  data  being  analyzed,  or  slower  determination. 

2  4.7.9  Balance  Management  [7.4.7.9} 

AVS  Implementation:  The  AVS  implemented  a  balance  management  function  in  determining 
release  sequences.  Each  potential  release  was  checked  for  the  balance  impacts  of  successful 
release,  and  if  balance  limits  would  be  exceeded  then  an  alternative  store  was  selected.  The 
balance  limits  set  were  a  maximum  lateral  imbalance  of  one  store. 

Other  Rationale;  The  AVS  balance  algorithm  is  typical  of  many  current  implementations  but 
several  factors  lead  to  reconsideration  for  future  aircraft: 

a  The  increased  use  and  delegated  authority  to  active  flight  stability  designs  reduce  the 
potential  burden  on  aircrew  caused  by  short  term  aircraft  imbalance. 

b.  The  trend  to  reduced  observability  places  additional  constraints  on  weight  imbalance 
and  stability  augmentation. 
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c.  The  potentially  reduced  use  of  under-wing  pylons  for  store  mounting  increases  the 
longitudinal  distribution  of  heavy  stores  in  internal  bays  and  may  necessitate  a  longitudinal 
balance  constraint  on  potential  releases. 

d.  The  weight  of  a  single  store  can  typically  vary  between  100  and  1500  kg  (200  - 
3000  pounds).  Individual  store  weights  may  have  to  be  considered  in  determining  whether  a 
potential  release  was  safe.  Store  weight  can  potentially  be  determined  via  the  MIL-STD-1760 
interface. 

While  the  balance  function  is  inherently  an  SVS  function  factors  b.  and  d.  above,  taken  with  the 
previous  observations  on  hang  up  detection  lead  to  a  close  link  with  the  AIS  being  required. 

Conclusion:  Implement  in  the  AIS  if  also  implementing  the  SMS  function. 

2.4.7.10  Engine  Control  Assistance  (7.4.7.10) 

AVS  Implementaticn:  No  engine  contiol  assistance  function  was  implemented  by  the  AVS. 

Other  Rationale:  Engine  assistance  will  depend  on  three  key  inputs:  the  engine  static  and 
dynamic  conditions,  the  weapon  release  characteristic,  and  the  location  of  the  weapon.  The 
outputs  of  the  function  will  be  data  to  the  engine  management  system  and/or  to  the  weapon  (via 
the  MIL-STD-1760  interface).  The  function  is  more  related  to  the  SMS  function  than  the  AIS 
and  it  is  therefore  best  implemented  in  the  AIS  only  if  a  separate  SMS  is  not  fitted. 

2.4.8  Store  Jettison  (7.4.8) 

2.4.8.1  Jettison  Prompt  (7.4.8) 

As  with  the  Release  and  Arming  prompts  (see  2.4.6  and  2.4.7)  this  is  not  an  AIS  function. 

2.4.8  2  Selective  Jettison  Management  (7.4.8.2] 

AVS  Implementation:  The  AVS  implemented  the  following  Selective  Jettison  functions: 

a  Management  of  Suspension  Equipment 

b.  Retention  of  Selective  Jettison  package 

c.  Interlock  of  Selective  Jettison  with  received  discrete  and  avionics  bus  data 

d.  Stores  set  to  safe  state 

e.  Sequenced  jettison  of  selected  stores  on  demand 

Of  these  sub  functions  only  the  setting  of  stores  to  a  safe  state  necessitated  close  links  with  the 
MIL-STD-1760  Interface.  The  conclusion  is  that  the  Selective  Jettison  Management  function,  as 
implemented  by  the  AVS,  was  an  SMS  function  and  should  not  be  located  in  the  AIS  unless  also 
implementing  the  SMS  function. 

Other  Rationale:  Close  links  with  the  AIS  function  will  be  required  where  secure  data  (such  as 
target  locations,  threat  libraries  or  guidance  link  characteristics)  have  been  programmed  into 
the  store.  In  such  circumstances  either  the  store  would  not  be  jettisoned,  or  classified  data 
erasing  may  be  commanded  via  the  MIL-STD-1760  interface. 

Conclusion:  Not  an  AIS  function  unless  also  Implementing  the  SMS. 

2.4.8.3  Emergency  Jettison  Management  [7.4.8.3) 
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AVS  Implementation;  In  the  AVS,  Emergency  Jettison  differs  only  from  Selective  Jettison  in  the 
following  areas: 

a  A  different  input  prompts  the  activity. 

b.  All  stores  are  jettisoned. 

c.  A  secondary  mechanism  is  involved  after  the  sequenced  jettison  that  ensures  all  stores 
are  jettisoned. 

None  of  these  differences  is  related  to  MIL-STD-1760  implementation  and  therefore  the 
conclusion  obtained  above  for  Selective  Jettison  is  still  valid. 

Conclusion:  Not  an  AIS  function  unless  also  implementing  the  SMS. 

2.4.8.4  Store  Safe  Verification  (7.4.8.4) 

AVS  Implementation:  In  the  AVS,  Stores  were  set  safe  before  jettison  by  two  mechanisms: 

a  Setting  all  MIL-STD-1760  stores  safe  by  data  bus  demands  and  by  setting  Release 
Consent  inactive 

b.  Setting  all  Nose  Fuzing,  Tail  Fuzing  and  Master  Arm  signals  to  the  S  &  RE  to  inactive 

states 

This  cannot  be  considered  as  true  verification  because  stores  that  failed  to  achieve  a  safe  state  or 
which  could  not  be  monitored  for  safe  status  were  still  jettisoned.  The  verification  mechanism  of 
using  two  ''independenr  inputs  (data  bus  and  Release  Consent)  to  the  store  to  demand  safe  state 
has  weaknesses  in  that  in  the  contracted  issue  of  MIL-STD-1760  Release  Consent  is  not  a 
guaranteed  interlock  on  Arming.  For  the  AVS  all  store  definitions  do  have  Release  Consent  as  such 
an  interlock  and  MIL-STD-1760  Notice  3  also  forces  such  an  interlock.  Problems  were  also 
encountered  due  to  the  management  of  a  carriage  store.  During  jettison  this  required  Release 
Consent  to  be  active  at  the  ASI  to  jettison  the  carried  stores.  All  other  stores  required  Release 
Consent  de-energized  at  the  ASI.  Because  of  the  high  use  of  MIL-STD-1760  in  implementing 
this  function  and  the  commonality  in  signal  types  between  Release  Consent  and  existing  store 
fuzing/arming  signals,  this  function  is  best  implemented  in  the  AIS. 

Conclusion:  implement  in  the  AIS. 

2.4.9  Inventory  (7.4.9) 

2.4.9.1  Inventory  Determination  (7.4.9.1] 

AVS  Implementation;  The  AVS  implemented  a  fully  automatic  mechanism  for  determining  the 
store  loadout.  Each  station  was  interrogated  for  the  following  data; 

-  MAU-12  indicaling  weapon  or  launcher  loaded  -  MIL-STD-1760  interlock  status 

-  MIL-STD-1553  response  when  power  applied  -  MIL  STD-1760  store  identification  data 

-  AIM-9L  ident  discrete  (28  Volt) 


307 


From  these  inputs  the  AVS  can  unambiguousiy  determine  the  exact  loadout  at  every  station  with 
no  further  crew  or  aircraft  input  needed.  The  AVS  implementation  can  however  be  criticized 
from  several  viewpoints: 

a  The  AVS  existing  store  inventory  is  extremely  limited  and  ambiguity  would  result  If 
more  existing  stores  were  Mfded  as  many  would  respond  identically  to  the  above  data  list. 

b.  MIL-STO-1760  stores  and  AMRAAM  (only  electrically  compatible  with 
MIL-STD-1760)  were  differentiated  in  the  AVS  only  by  use  of  two  unique  characteristics. 

First,  all  the  MIL'STD-1760  mission  stores  in  the  AVS  inventory  have  MIL-STD-1553 
interfaces  powered  by  28  Volts.  Secondly  AMRAAM  has  a  MIL-STD-1553  interface  powered 
from  115  Volts.  These  enabled  a  test  of  MIL-STD-1533  response  with  28  Volts  applied  and  no 

1 15  Volts  to  determine  the  store  as  MIL-STD-1760  and  not  AMRAAM.  This  test  obviously  cannot 
work  with  a  wider  inventory  of  MIL-STD-1760  stores  some  of  which  might  have  remote 
terminals  powered  by  115  Volts. 

c.  The  location  determination  of  MIL-STD  1760  stores  in  the  AVS  is  d'l^'-or^^nt  on 
MIL  STD-1553  remote  terminal  addresses.  This  could  lead  to  misinterpreted  inventory  under 
any  of  the  following  conditions. 

( 1  )  Store  responding  to  more  than  one  MIL-STD- 1553  address. 

( 2)  Failure  of  MIL-STO-1760  address  discretes  (a  parity  check  is  implemented 
but  continuity  failures  are  most  probable  following  new  store  connection). 

(  3 )  Failure  of  MIL-STD-1760  data  bus  controller  to  set  addresses  correctly. 

In  conclusion  it  would  be  inadvisable  to  use  the  AVS  inventory  mechanism  to  solely  determine 
inventory. 

Other  Rationale:  The  AVS  discussion  above  has  highlighted  the  problems  of  implementing  an 
automatic  inventory  determination  mechanism.  These  problems  are  centered  on  existing  stores 
(including  AMRAAM)  which  provide  insufficieni  data  to  be  uniquely  identified. 

Conclusion:  Inventor/  cannot  be  determined  via  the  AIS  and  therefore  must  be  a  crew  or  airaaft 
function. 

2.4.9.2  Inventory  Confirmation  (7.4.9.2) 

AVS  Implementation:  No  mechanism  for  inventory  confirmation  is  implemented  in  the  AVS.  The 
presumption  is  that  the  crew  will  compare  the  displayed  slore  loadout  with  written  data  (from 
briefing).  This  is  not  a  system  to  be  recommended  for  future  aircraft  because  of  the  danger  of 
misinformation  and  the  increased  crew  workload.  The  Inventory  Determination  implemented 
could  be  considered  as  a  confirmation  function. 

Other  Rationale:  If  it  is  assumed  that  the  AIS  is  not  used  as  the  inventory  determination  system 
then  a  separate  inventory  panel  or  mission  briefing  tape  or  even  direct  crew  input  will  provide 
the  basic  inventory  data.  This  data  should  be  considered  critical  for  these  reasons: 

a  If  inventory  is  not  correctly  known  the  aircraft  may  be  placed  into  an  unsafe  dynamic 
position  due  k>  balance  or  other  effects. 
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b.  If  inventory  is  not  correctly  known  the  aircrew  may  be  misinformed  as  to  the 
feasibility  of  various  mission  roles. 

It  is  therefore  advisable  to  implement  an  inventory  confirmation  function  in  the  airaaft.  The 
AVS  type  inventory  determination  function  described  in  [7.4.9. 1)  above  is  suitable  for  this 
function.  Such  a  rnechanism  has  the  following  input  data; 

a  MIL-STD-1760  interlock,  MIL*STD-1553  response  and  Store  Description  data 
available  to  the  AIS. 

b.  Suspension  and  Release  Equipment  monitor  switches  and  existing  store  continuity 
discrete  data  available  to  the  SMS. 

Clearly  a  combined  AIS  and  SMS  is  the  best  approach  with  the  AIS  (if  separate)  implementing  the 
inventory  confirmation  function  for  MIL-STD-17S0  stores. 

Conclusion;  Implement  inventory  confirmation  in  the  AIS. 

2.4.9.3  inventory  Update  [7.4.g.3] 

AVS  Implementation;  Inventory  update  was  implemented  fuily  in  the  AVS.  MIL-STD-1760, 
MAU-12,  and  Modular  Rail  Launcher  (MRL)  data  was  interrogated  and  changes  to  inventory 
determined  in  cases  of;  store  failure,  store  release,  and  store  jettison.  The  function  is 
representative  of  that  required  in  a  ^ture  system. 

Conclusion;  Implement  Inventory  Update  in  the  AIS  unless  a  separate  SMS  is  implamented. 

2.4.10  Craw  Interface  (7.4.10) 

2.4.10.1  Displays  (7.4.10.1) 

AVS  Implementation:  The  AVS  implemented  a  multifunction  display  system  to  enable  operator 
monitoring  of  the  AVS  and  stores.  The  display  used  was  dedicated  to  the  AVS  although  data  access 
to  all  avionics  data  was  available  via  a  MIL-STO-1553  remote  terminal  to  the  Avionics  Bus.  The 
AVS  implementation  cannot  be  considered  to  be  fully  representative  of  a  future  implementation 
for  two  reasons: 

a  Display  Systems  are  r^uired  to  be  more  flexible  and  interface/display  data  from 
multiple  systems  to  provide  for  failure  tolerance  and  reduced  cockpit  sizes. 

b.  Most  future  aircraft  avionics  architectures  avoid  interfacing  the  display  system  to  an 
avionk^  MIL-STD-1553  data  bus  because  of  bus  loading  problems  (the  AVS  display  system  uses 
approximately  6%  of  available  bus  time).  Instead  a  display  system  bus  is  implemented  in 
MIL-STD-15^  or  High  Speed  Data  Bus. 

The  AVS  Implementation  should  be  seen  as  implemeniing  both  an  AIS  and  a  display  system. 

Other  Rationale:  Aircraft  display  systems  typically  execute  very  high  speed  low  level  processing 
of  preprocessed  data  into  visible  displays.  The  external  preprocessing  of  the  data  usually 
produces  high  level  store  data  such  as  status,  location  and  modes.  This  data  is  abstract  from  most 
MIL-STD-1760  data  forms  and  is  therefore  considered  to  hawe  been  preprocessed  by  the  AIS  (or 
SMS)  system. 
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Conclusion:  Displays  are  not  an  AIS  function. 
2.4.10.2  CfiUcal  Controls  17.4.10.21 


AVS  lnf)plementation:  The  AVS  Implemented  the  following  critical  controls  as  switches  directly 
connected  to  the  PCE: 

Trigger  Selective  Jettison 

-  Emergency  Jettison  -  Master  Arm 

Another  input  sometimes  considered  critical  was  the  AIR  or  GROUND  status.  This  was 
implemented  as  avionics  bus  data. 

The  above  controls  were  seen  as  criucal  to  the  provision  of  MIL-STD-1760  critical  control  data 
where  the  requirement  of  1  in  10^  hours  inadvertent  error  rate  was  a  prime  design  driver.  To 
achieve  this  design  requirement  special  care  was  taken  in  processing  the  data  from  these  inputs. 
Provisions  included: 

a  Switches  were  a  minimum  of  two  poles.  Each  switch  pole  having  normally  open  and 
closed  contacts  to  provide  a  minimum  of  four  data  inputs  to  the  AVS. 

b.  Separate  data  paths  were  implemented  for  the  separate  switch  poles.  These  paths 
were  separately  processed  with  the  output  data  being  reformed  at  the  PCE  MIL-STD-1760  dala 
bus  controller.  One  path  produced  the  critical  control  data  and  one  path  the  critical  authority 
axles. 

The  AVS  implementation  is  representative  of  the  design  techniques  that  would  be  required  in  a 
future  implementation.  The  number  of  criticai  switches  could  be  expected  to  be  higher  however 
as  mt  Itiple  crew  and  multiple  release  demands  for  air  to  air  and  air  to  ground  roles  may  be 
implemented. 

Other  Rationale:  The  critical  inputs  described  for  the  AVS  are  also  typical  inputs  for  the  aircraft 
SMS  function.  Figure  2.7  shows  four  possible  implementations  for  the  SMS  and  AIS  functions 
without  requiring  separate  sets  of  Ciitical  switches  in  the  cockpit  (considered  unacceptable  due 
to  crew  workload).  In  f^ure  2.7a,  the  AIS  provides  part  processed  critical  input  data  to  the  SMS 
function.  This  has  the  disadvantage  that  the  SMS  safety  analyses  and  derived  performance  is 
degraded  by  the  AIS  safety  performance  before  any  SMS  circuitry  and  software  is  analyzed.  In 
figure  2.7t,  the  AIS  receives  from  me  SMS  part  processed  critical  input  data.  This  similarly 
has  the  disa>dvantage  that  the  SMS  safety  performance  degrarfes  the  AIS  safety  performance.  Ir* 
figure  2.7c,  p  combined  AIS/SMS  receives  the  raw  critical  input  data.  Because  the  combined 
system  can  lr.';plement  common  sub-functions  there  is  significantly  less  safety  degradation. 
Additionally,  the  safety  design  is  controlled  by  one  design  authority,  thereby  reducing  hazards 
due  to  ambigu  ties  and  unnecessary  overdesign.  In  figure  2.7d,  the  critical  inputs  are  parallel 
input  into  separcMe  AIS  and  SMS  systems.  This  results  in  no  safety  degradation  but  a  degree  ot 
unnecessary  design  and  build  duplication.  Both  2.7c  and  2  7d  represent  good  implementations. 

In  both  cases  the  critical  controls  can  be  considered  to  be  in  the  AIS  for  MIL-STD-1760  stores. 

Conclusion:  Implement  critical  controls  as  part  of  the  AIS. 

2.4.10.3  Non  Critical  Controls  [7.4.10.3] 

AVS  Implementation;  The  AVS  irnpienented  ail  non  criticai  controls  as  part  of  the  display  system 
(see  (7.4.10.1)).  Typical  controls  provided  were: 
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Critical 

Inputs 


a.  SMS  Dependent  on  AIS 


Critical 

Inputs 


b.  AIS  Dependent  on  SMS 


Critical 

Inputs 


Critical 

Inputs 


c.  Combined  AIS/SMS  d.  Parallel  Wiring 

FIGURE  2.7  Crlticai  Switch  Implementation 


Store  type  selection  Targeting  mode  selection 

BIT  demands  Release  Package  selection 

These  data  inputs  are  of  a  higher  level  form  than  those  of  MIL-STD-1 760  and  therefore  require 
processing  in  the  AIS.  As  such,  the  non  criticai  controls  of  the  AVS  can  be  considered  similarly  to 
the  displays  as  being  an  additional  function  separate  from  the  AIS  function. 

Other  Rationale:  Effectively  as  for  [7.4.10.1] 

Conclusion:  Non  critical  controls  rre  not  an  AIS  function. 
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2.4.11  Nuclear  Contrcl  [7.4.11] 


AVS  Implementation:  The  AVS  implements  no  nuclear  weapons  in  its  inventory.  System  level 
expansion  provision  was  originally  made  to  add  on  nuclear  weapons.  Such  additions  would 
require  the  following  changes: 

a  Addition  of  Special  Weapon  control  panels  to  enable  tx)  crew  input  of  NRC,  NAC  and 
PAL  data.  These  panels  would  interface  to  MIL-STD-1553  avionics  bus  and  via  discrete  signals 
to  other  equipment. 

b.  Addition  of  special  discrete  signals  to  the  AVS  armaments  bus.  These  would  convey 
NRC  data  to  the  SSE  at  the  Nuclear  Weapon  stations. 

c.  Replacement  of  SSE  at  Nuclear  Weapon  stations  with  nuclear  certified  SSE.  These 
would  be  essentially  to  the  same  design  as  the  current  SSE  but  would  implement  additional 
independent  circuitry  to  drive  the  MAU-12  In  Flight  Operable  Lock  (IFOL)  by  command  from  the 
Armament  Bus  interkvSted  with  added  discretes  as  described  in  b.  above. 

d.  Addition  of  Aircraft  Monitor  and  Control  (AMAC;  System  1  controller  interfacing  to 
the  Armaments  Bus  and  the  extra  Special  Weapon  panels.  PAL  data  would  be  transferred  from  the 
Special  Weapon  panels  via  the  PCE  and  the  MIL-STD-1533  Armaments  Bus. 

e.  Addition  of  Nuclear  Weapon  Control  software  to  the  PCE  software.  This  would  require 
modification  to  all  processing  parts  of  the  PCE  including  the  critical  code  generation.  All  of  the 
PCE  software  would  require  nuclear  certification. 

Other  Rationale;  Consideration  of  various  areas  of  Nuclear  Weapon  Control  for  inclusion  in  the 
AIS  can  be  by  analysis  with  conclusions  reached  for  conventional  stores.  Very  few  aspects  of 
nuclear  weapon  control  are  different  in  function  from  conventional  weapons.  The 
implementation  differences  arise  from  three  areas: 

a  The  certainty  levels  required  are  typically  between  10®  and  10^  higher  than  with 
conventional  stores. 

b.  Specific  design  requirements  are  detailed  in  Air  Force  and  Navy  documents. 

c.  The  involvement  of  various  other  agencies  (for  example  the  Department  of  Energy  and 
Sandia  Labs)  is  mandated  at  various  stages  in  the  design  process. 

Conclusion:  Nuclear  weapon  functions  should  be  implemented  in  the  AIS  if  the  equivalent 
conventional  weapon  function  is. 

2.5  Future  Growth  Potential  [7.5] 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 
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3.  RATIONALE  FOR  APPENDIX  A  SECTION  8 


Paragraphs  3.1  through  3.4  of  this  section  provide  rationale  derived  from  the  AVS  and  other 
sources  to  support  the  guidance  given  in  paragraphs  8.1  through  8.4  of  Appendix  A.  Issue 
statements  and  subject  titles  have  been  summarized.  Where  rationale  was  supplied  in  the 
guidance  text  and  further  provision  is  considered  superfluous,  then  extra  rationale  is  not 
supplied. 

3.1  Approach  [8.1] 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

3.2  AIS  Functional  Performance  [8.2] 

3.2.1  Store  Interface  Performance  [8.2.1] 

3.2.1.1  MU--STD-1760  ASI  [8.2.1. 1] 

3.2.1. 1.1  Number  [8.2.1.1.11 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

3.2. 1.1.2  Categories  [8.2.1.1.21 

ISSUE:  What  category  of  ASI  should  be  implemented. 

AVS  Implementation:  The  AVS  implemented  2  class  I  ASIs,  3  class  lA  ASIs,  and  2  class  II  CSSis. 

All  mission  stores  managed  by  the  AVS  can  be  supported  by  a  class  II  ASI  or  CSSI.  No  class  I  or 
auxiliary  services  are  needed. 

Implementation  Survey:  Refer  to  section  7.3  of  the  application  guidelines  report  for  detail 
background.  No  hard  requirement  for  high  bandwidth  lines  has  been  found  and  the  requirement 
for  auxiliary  power  is  very  limited.  No  store  requirement  for  the  270V  DC  or  Fiber  Optic 
interfaces  is  yet  evident. 

Other  Rationale:  The  requirement  for  four  high  bandwidth  lines  is  only  substantially  supported 
by  stores  such  as  the  LANTIRN  pod.  it  is  likely  that  such  stores  will  continue  to  be  developed  on 
an  aircraft  target  specific  basis  and  these  aircraft  can  provide  the  necessary  additional 
interfaces.  The  implementation  difficulty  for  high  bandwidth  signals  is  directly  proportional  to 
the  number  of  interface  signals  implemented.  Auxiliary  power  has  few  applications  other  than 
for  multiple  carriage  stores.  No  full  MIL-STD-1760  carriage  stores  are  known  to  be  currently 
planned  because  of  the  necessaiy  electronic  complexity  of  a  MIL-STD-1553  remote  terminal  and 
bus  controller,  the  availability  of  an  alternative  solution  (wnere  multiple  stores  are  carried  on 
a  carriage  store,  but  are  electrically  linked  to  separate  ASIs  on  the  aircraft  structure)  and  the 
reduced  use  of  carriage  stores.  The  “provisions’  interfaces  for  Fiber  Optic  and  270  Volt  signals 
are  not  currently  required.  Indeed  there  must  be  some  considerable  doubt  whether  they  will  be 
used  in  the  medium  term.  Store  designers  would  currently  have  to  design  for  compatibility  with 
interfaces  that  do  not  have  these  capabilities  and  for  the  stores  to  also  use  Fiber  Optic  or  270V 
DC  signals.  This  would  place  an  unacceptable  burden  on  store  design.  The  resolution  of  this 
problem  could  be  by  the  government  mandating  Fiber  Optic  and  270V  DC  aircraft  implementation 
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(difficult  given  the  projected  costs),  or  a  store  re<^iring  these  interfaces  to  achieve  required 
performance  (nc  such  projected  stores  known),  or  else  the  signals  will  not  be  used. 

3.2.1. 1.3  Aircraft  Capacity  (8.2.1. 1.3) 

ISSUE:  How  many  ASI  should  be  available  for  simultaneous  use? 

AVS  Implementation;  The  AVS  provided  for: 

a  Aii  ASIs  to  be  simultaneously  connectable 

b.  All  ASIs  to  be  simultaneously  fully  powered.  It  should  be  noted  that  the  AVS  only 
implemented  five  ASIs  and  the  necessary  power  wiring  to  support  this  performance  was  a 
considerable  stress  on  the  design. 

c.  Two  ASIs  al  a  time  to  be  actively  controlled.  This  included  full  targeting  of  connected 

stores. 

Other  Rationale:  The  AIS  processing  and  data  bus  loading  will  tend  to  be  directly  proportional  to 
the  number  of  stores  being  actively  targeted.  Should  this  number  be  limited  to  less  than  two  then 
the  aircraft  will  be  severely  limited  in  operational  performance.  Two  ASI  targeting  provides 
for: 


a  A  target  to  be  tracked  and  attacked  even  if  either  it  is  obscured  to  one  store  by  aircraft 
structure  or  one  store  fails  during  the  release  phase 

b.  Two  targets  to  be  attacked  at  a  time.  In  practice  this  number  is  increased  by  the 
number  of  targets  already  attacked  by  stores  in  free  flight  and  targets  yet  to  have  stores  launched 
to  attack  but  have  already  been  programmed/acquired  for  attack. 

Allowing  for  four  ASIs  to  be  fully  powered  will  provide  a  potential  power  load  of  16  KW  by  the 
AIS  and  connected  stores  and  require  input  cabling  capable  of  canying  50  Amps.  To  increase  the 
number  fully  powered  will  proportionally  increase  this  design  stress.  To  reduce  the  number 
fuliy  powered  below  four  will  limit  operational  performance.  Many  stores  require  several 
seconds  to  become  operational  after  power  up  and  therefore  when  attacking  multiple  targets  it  is 
necessary  to  'pre-warm'  some  stores  other  than  those  being  targeted.  Setting  a  minimum  of  four 
provides  for  two  stores  always  to  be  available  following  release  of  the  minimum  of  two  being 
targeted. 

3.2.1 .2  MSI  (8.2.1.21 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  ar>d  no  further  rationale  is 
necessary. 

3.2.1. 3  Non  AEIS  Signals  18.2.1 .3) 

ISSUE:  How  should  these  be  specified? 

AVS  Implementation:  The  AVS  implemented  two  AIM-9L  and  six  MK*82  bomb  statkx^.  Only  one 
station  at  a  time  could  be  actively  targeted  or  released  although  Iracking”  guidance  for  two 
missiles  and  pairs  release  (through  staggered  release  of  two  bombs)  was  irr^mented.  To 
increase  this  AVS  performance  would  proportionally  increase  the  relevant  AVS  complexity. 
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RATIONALE:  The  rationale  was  provided  in  the  Appertdix  A  guidance  and  no  further  rationale  is 
necessary. 

32.1.4  Suspension  and  Post  Launch  Interfaces  (8.2.1. 4.  8.2.1. 5] 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

3.2.2  Slorg  staifl  (8.2.2] 

3.2.2.1  State  Change  Prompt  (8.2.2.1| 

ISSUE:  How  to  specify  the  relevant  performance? 

A  VS  Implementation:  The  AVS  changed  the  state  of  stores  on  detection  of  the  following  events; 
crew  input,  store  failure,  and  store  release.  No  problems  were  found  with  this  implementation. 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

3.2.2.2  State  Command  (8.2.2.2] 

ISSUE:  AIS  performance  for  Store  State  Commands. 

AVS  Implementation:  The  AVS  implementation  is  essentially  identical  to  that  given  in  Appendix  A. 
Differences  relate  principally  to  up^tes  for  the  change  between  the  contracted  and  ihe  current 
issues  of  MIL-STO-1760.  The  AVS  design  was  not  made  significantly  more  complex  by  the 
requirement  to  meet  this  performance  once  the  design  impact  of  imptementing  both  the  SMS 
function  and  the  MIL-STD-1760  bus  controller  safety  requirement  is  disregarded. 

Other  Rationale: 

a  Inputs  •  No  further  rationale  is  required. 

b.  Outputs  -  These  are  the  only  state  command  outputs  specified  in  MIL-STD-1760.  The 
formats  are  as  defined  in  MIL-ST0-17M.  No  definite  inhibit  or  enable  condition  for  Release 
Consent  can  be  specified  for  jettison  because  some  stores  may  require  it  to  be  enabled  and  some 
may  require  it  to  be  inhibited  (to  disable  fuzing/arming). 

c.  Discrepancy  -  The  key  dependencies  specified  are  on  the  critical  switch  inputs.  The 
dependency  provides  for  the  following  uses  of  the  switches  listed  below.  A  clear  interpretation  of 
critical  switches  is  essential  for  Ihe  retention  of  safety. 


(1) 

critical  inputs 

(2) 

(3) 

stores 


Master  Arm  -  Reduction  of  safety  and  increase  of  readiness  for  further 

Trigger  -  Initiation  of  launch  and  fire  processes  for  air-to-air  stores 
Weapon  Release  -  Initiation  of  launch  and  release  processes  for  air  to  ground 


315 


( 4  )  Selective  Jettison  -  as  seiective  jettison  but  for  the  emergency  ieiuron 

functions 

d  Timing  -  Timing  specification  is  directly  related  to  total  vveapon  system  perf'^rmance 
and  therefore  only  minimum  performance  is  detailed.  Specifying  80  ms  for  safety  critical 
change  state  sets  a  limit  for  the  uncertainty  of  ttte  store  state  and  the  delay  times  to  be 
compensated  for  in  computing  launch  points.  To  specify  a  shorter  time  would  require  a  high 
degree  of  interrupt  driven  processing  and  bus  control  flexibility  in  every  application.  The 
specification  of  10  seconds  for  other  state  changes  provides  an  absolute  minimum  performance 
that  must  be  available  in  every  AIS.  This  only  ensures  that  state  changes  will  occur  in  real  time. 
The  required  performance  will  always  be  highly  dependent  on  slate  type,  store  type  aiKf  mission. 
For  example  to  track  moving  targets  move  changes  with  maximum  50  ms  delay  are  often 
required. 

e.  Assurance  -  The  success  per  ASI  of  1 0'^  failure  after  one  hour  is  equivalent  to  the 
performance  of  [8.3.2.2)  for  a  ten  ASI  mission.  The  same  applies  for  the  safety  cases  of  10'^ 
for  Jettison  and  Master  Arm/Weapon  Release  relative  to  (8.3.2.3]. 

The  specification  of  10'^  after  one  hour  for  error  if  either  Master  Arm  or  Weapon  Release  is 
incorrectly  interpreted  demanded,  is  derived  from  MIL'STD-1760  Notice  3  table  B-XXXII  Note 
4  for  a  ten  ASI  mission.  The  other  cases  performance  of  10'^  relate  mainly  to  mission  success 
and  the  avoidance  of  not  selecting  an  ineffective  mission  store  state. 

3.2.2  3  State  Monitor  (8.2.2.3j 

ISSUE:  AIS  Performance 

AVS  Implementation;  The  AVS  performance  differs  from  that  specified,  in  three  areas; 

a  The  basic  timing  figure  of  100  mS  was  modified  according  to  the  type  of  state  change 
demanded  but  was  always  before  50  ms  had  elapsed.  This  provided  a  stress  to  the  design  as  it 
increased  the  processing  and  bus  load  peaks  associated  with  state  changes. 

b.  A  time  out  of  500  ms  was  imposed  for  state  achievement.  Such  a  timeout  would  not 
work  with  many  projected  MIL'STD-1760  stores  where  state  achievement  may  take  minutes. 

c.  No  regular  polling  of  0.5  Hz  was  established- 

Other  Rationale:  It  is  vital  to  safety  that  a  store  is  closely  monitored  to  ensure  it  does  not  attain  a 
dangerous  state.  Once  a  store  has  been  delected  as  potentially  attaining  a  dangerous  state  several 
actions  can  be  taken  to  correct  the  safety  hazard.  These  include: 

Data  Bus  commands  Release  Consent  set  to  cfeable 

Removal  of  store  power  Jettison  of  store 

The  highest  probability  of  attaining  incorrect  states  arise  when  a  state  change  is  being 
accomplished  and  therefore  a  maximum  uncertainty  time  Of  100  ms  is  spedfied  for  those  times. 
During  rKirmal  stable  operation  the  uncertainty  time  is  calculated  at  2  seconds  from 
consideration  of: 

a  The  low  probability  of  state  corruption 

b.  The  highty  critical  nature  of  some  states 

c.  The  data  bus  load  imposed  (approximately  0.05%  per  store) 
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3  2^.4  Power  Supotv  Manaflemant  f8.2.2.41 
ISSUE:  AIS  Performance 

AVS  Implementation:  This  is  as  stated  in  Appendix  A.  No  probtems  were  caused  in  the 
implementation  of  these  requirements. 

Other  Rationale: 

a.  If  power  is  not  present  when  it  is  required  then  store  state  failures  will  occur 

b.  Power  should  be  applied  frugally  because  of  the  limited  power  available  in  aircraft 
and  the  useful  life  degradation  of  powered  stores.  Special  care  Is  required  with  28V  DC  Power  2 
and  Auxiliary  28  Volts  as  many  stores  can  be  guaranteed  to  be  safe  when  these  supplies  are  not 
powered. 


c.  Four  ASIs  must  be  able  to  be  powered  (from  [8.2.1. 1.3]) 

3.2.3  Data  to  Store  (8.2.3] 

3.2.3.1  Dat^  Source  [8.2.3.1] 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

3.2.3.2  Aircraft  Data  |8.2.3.2] 

3.2.3.2.1  Formats  [8.2.3.21] 

ISSUE:  What  formats? 

AVS  Implementation:  The  AVS  received  all  aircraft  data  in  MIL-STD-1 760  data  formats.  This 
simplified  and  improved  the  performance  achieved  in  data  transfer  to  stores. 

Other  Rationale:  The  use  of  MiL-STD-1760  data  entity  definitions  and  formats  in  all  avionic 
systems  would  simplify  and  improve  systems.  TNs  is  not  likely  to  be  easily  achieved  because  of 
a  number  of  factors: 

a  Standanfization  of  equipment  types  such  as  INS  and  Air  Data  may  not  be  compatible 
with  the  MIL-STO-1760  formats. 

b.  MIL-HDBK-1553  does  not  always  conform  to  MIL  STD-1760  formats. 

c.  Retrofits  of  MIL-STO-1760  to  current  aircraft  will  have  to  be  compatible  with  the 
existing  data  formats  in  use. 

3.2.3  2.2  Data  AvailahiiitY 

ISSUE:  Which  data  types  should  be  available? 

AVS  liTHslementation:  The  AVS  fo^ilemerrted  a  very  genera  form  of  airc^afi  data  interface.  Most 
MIL*ST0*1760  data  entities  deriv^  from  aircraft  sources  were  implemented  and  given  unique 
subaddress/word  positions.  hfoUfole  limitations  were  the  NrNted  rujmber  of  simultaneous  targets 
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and  the  exclusion  of  aircraft-store  alignment  data  (required  ¥vhen  stores  are  moved  inside 
wee^n  bays  or  on  swing-wings).  Most  of  this  data  was  unused  by  the  AVS  stores. 

Other  Rationale;  The  majority  cf  data  between  aircraft  and  stores  (via  the  AIS)  is  centered  on 
two  types  -  where  the  aircraft  is  and  where  the  targets  are.  Specific  Interface  provision  should 
therefore  concentrate  on  these  data  types.  Significant  exp^sion  provision  should  afso  be 
provided  for  the  unique  to  store  or  mission  data  types  that  may  be  required  to  be  added  to  the  AIS 
during  subsequent  updates  of  store  badout  cap^lity.  See  also  3.4.2  [8.4.2]  ft>r  more  detail  on 
interface  requirements. 

3.2.3.2.3  Data  Accuracies 
ISSUE:  What  accuracy? 

AVS  Implementatbn:  No  accuracy  pcrfomance  was  specified. 

Other  Ratbnale:  It  is  common  to  specify  data  accuracy  for  systems  on  a  store  by  store  basis. 

This  policy,  if  extended  to  the  AIS,  could  Mad  to  difficulties  if  a  new  store  requires  a  much  higher 
accuracy  than  possible  with  an  AIS  implemec’eo  with  only  a  limited  performance.  A  generic 
baseline  performance  must  therefore  be  specified.  Such  a  baseline  performance  is  stated  in 
Appendix  A  based  on; 

a  Cumulative  Error  Probability  (CEP)  of  ±.  10  meters 

b.  Maximum  target  angle  inaccuracy  cf  t.  0.5  degrees  (0.28  semicircles) 

c.  Moving  aircraft  and  targets  to  Mach  1  velocity 

d.  Partitioning  of  this  budgef  as  33%  inaccuracy,  67%  other  factors 

e.  Partitbning  of  ihat  budget'  as  50%  AIS,  50%  aircraft 

3.2.3  2.4  Data  Utency  and  Update  Rates 
ISSUE:  AIS  Performance? 

Background:  MIL  STO-1760  specifies  MIL-ST  ">-1553  as  the  prime  data  interface  between  the 
airaaft  and  store.  As  this  is  a  time  shared  communicatbn  system  there  is  no  continuous  data 
connection  between  aircraft  and  store  and  therefore  data  delays  are  inherent  in  the 
implementation  of  the  AIS.  Data  delays,  whether  due  to  latency  or  update  cycles,  can  be  as 
detrimental  to  system  performance  as  data  inaccuracies.  The  AIS  should  therefore  have  latency 
and  update  rate  characteristics  specified  for  the  most  affected  data  entities.  MIL-STD-1760  (as 
defined  by  June  '85  Notice  1)  specifies  four  categories  of  data: 

-  Control/monitor  data  entities  Aircraft  oata  entities 

Target  data  entities  Trajectory  data  entities 

Only  the  target  and  aircraft  data  entities  are  seriously  impacted  by  data  delays.  Indeed  they  a'e 
the  only  entities  with  change  rate  entities  also  Sfiedfied  for  the  correction  of  errors.  Therefore 
these  should  be  analyzed  as  the  indicators  for  performance  requirerrtents.  because  target  data  is 
more  sensitive  to  delays.  This  will  be  considered  first. 

3.2.3.2.4.1  Taroei  Data  Latency  and  Update  Rates  fto  stores) 

AVS  Implementation;  Performance  for  the  AVS  was  specified  for  update  rates  but  not  for  data 
latency.  A  25Hz  update  rate  was  specified  for  an  existing  store  (AIM-9L  Sidewinder)  and  that 
figure  also  specified  foi  two  projected  MiL-STD-1760  weapons  of  comparable  ability  to  AIM-9L 
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and  MavericK.  fhe  update  rate  was  selected  to  provide  for  acquisition  of  a  Mach  2  target  at  lOKm 
(6  miles)  range  with  the  fcliowing  assumptions: 


a  Maximum  average  error  for  target  lock  -  1/2^ 

b.  10%  of  error  budget  ailowed  for  update  rate 

c.  Target  crossing  aircraft  axis  at  right  angles  (worst  case) 

This  requirement  caused  few  problems.  Even  with  two  targets  being  tracked,  target  updating  to 
stct93  contributed  less  that  5%  of  maximum  theoretical  armament  bus  loading.  The  following 
text  provides  rationale  for: 

Target  data  Aircraft  data 

Implementation  difficulty  Analog  data 

Data  Latency  was  not  spedfk^lly  specified  but  aggressive  goais  were  set  in  the  AVS  design  in 
order  to  evaluate  the  difficulties  in  achieving  tow  data  latencies.  Latencies  of  between  8  ms  and 
64  ms  (average  43.1  ms)  were  measured  for  transfer  of  data  to  stores. 


Other  Raticr.ale:  Performance  specification  for  data  L  ency  and  update  rates  should  be 
considered  from  two  viewpoints:  desired  performance  and  the  impact  on  design  of  that 
performance.  As  will  be  explained  below,  achlevemsni  of  mandatory  operational  requirements  is 
partitioned  between  many  systems  (store,  aircraft)  other  than  the  AIS  and  it  is  the  AIS 
proporticn  of  the  required  total  performance  that  must  be  determined.  To  consider  desired 
performance  it  is  useful  to  analyze  a  particular  case.  A  dose  in  intercepiion  of  an  agile  air  to  air 
target  has  been  chosen  here  for  detail  consideration  es  a  stressing  case.  Referring  to  figure  3.1. 
a  target  is  shown  with  both  relative  velodt>'  and  acceleration  tc  the  host  aircraft. 


HOST:  VeSocity  =  Mach  1.5 
Accelerafion  =  1.5g 


TARGET:  Velocity  =  Mach  2.5 
Acceleration  =  2.5g 
Range  =  1150  meters 


/ 

FIGURE  3.1  Stressing  Case  for  Data  Latency  and  Update  Rates 


Figure  3.2  then  shows  the  true  target  azimuth  to  the  host,  the  azimuth  perceived  by  the  store  and 
the  resulting  error.  The  error  is  caused  by  the  data  latency  and  update  rate.  No  compensation  by 
the  store  has  been  assumed.  If  the  store  will  only  lock  onto  the  target  if  the  average  error  is  less 
than  one  degree  then  the  target  will  not  be  acquired  as  the  average  error  is  more  than  twice  this 
figure.  Fortunately,  this  situation  is  unrepresentative  of  the  environment  for  the  AIS.  Although 
older  stores  such  as  Sidewinder  and  Maverick  can  only  slew  their  seekers  to  supplied  positional 
data,  the  more  recent  stores  can  compensate  for  latency  and  update  rates  by  use  of  time  tagged 
positional  and  rate  of  change  data.  This  aibws  the  store  to  recompute  the  correct  target  vectors 
by  extrapolating  the  received  position  through  time.  The  effect  of  this  is  shown  in  figure  3.3 
where  the  store  now  additionally  receives  and  processes  position  time  tags  and  target  velocity 
data.  It  is  further  assumed  that  the  velocity  data  is  10%  inaccurate.  This  is  riot  an  excessive 
amount  as  sensing  of  target  relative  velocities  is  more  difficult  than  target  positions  and 
frequently  is  only  possible  by  assuming  constant  velocities.  Analyzing  figure  3.3  it  can  be  seen 
that  the  average  seeker  error  is  now  less  than  0.3  degrees  and  the  target  will  be  acquired.  An 
important  area  not  yet  discussed  is  that  of  the  other  errors  in  targeting.  These  are  typically  the 
sensor  and  store  errors  through  data  latency,  update  rates  and  other  errors,  store  to  aircraft 
misalignment  and  non  compensation  for  aircraft  structure  distortion.  The  AIS  can  therefore  be 
given  only  a  proportion  of  the  overall  error  budget.  For  the  case  described  above  this  proportion 
would  be  higher  than  for  slower  less  agiie  targets  and  might  be  25%.  If  we  therefore  further 
assume: 

Maximum  error  angle  =  i  degree 

%  of  error  to  AIS  =  25% 

Relative  Mach  2.2  target  at  1150  meters  range  (660  mis) 

Velocity  sensing  error  =  10% 

Then  if  data  latency  »  L  and  Update  rate  =  U 

fL  +  1/Ul  *  1  X  0.25  limit  N  to  infinity 

2  N  arcTan  (660/1 150N)  x  0.1 

L  +  1/U  =  150  ms 

At  an  update  rate  of  25Hz  this  would  limit  the  maximum  latency  through  the  AIS  to  110  ms.  To 
further  define  the  partitioning  of  the  1 50  ms  budget  consideration  of  the  design  impact  is 
required.  Before  that  is  considered  the  impact  of  target  acceleration  and  the  requirements  of 
other  store  types  should  first  be  considered.  Because  of  the  difficulties  in  sensing  target 
accelerations  it  is  effectively  impossible  to  directly  compensate  for  acceleration  errors. 
Acceleration  of  a  target  however  has  a  relatively  insignificant  impact  compared  to  velocity 
errors.  For  the  latency  and  update  rate  figuie  of  150  ms  derived  above,  the  target  would  have  to 
be  maneuvering  at  22g  to  have  as  much  effect  as  the  velocity.  This  is  not  seen  as  a  likely 
situation.  Table  3.1  shows  approximate  velocity  and  acceleration  combinations  compatible  with 
the  150  ms  figure.  The  previously  derived  figure  of  150  ms  would  therefore  seem  to  be  a  valid 
latency  and  update  ‘budget”  for  a  wide  range  of  potential  targets. 


TABLE  3.1  Velocity  and  Acceleration  Combinations 


Acceleration  (g) 

0 

22 

150 

1 

1  1 

150 

2 

2 

150 

2.2 

0 

150 
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Target 

Azimuth 


Target 


Error 
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Other  stores  to  be  cx>nsidered  can  be  of  many  types: 

Non  velocity/time  tag  compensating  stores  Air-to-Ground  Stores 

Beyond  Visual  Range  (BVR)  air-to-air  stores  Anti  Satellite  Stores 

It  is  possible  that  some  MIL-STD-1760  stores  will  be  developed  that  implement  no 
compensation  by  use  of  velocity/time  tag  data.  Three  options  are  available  for  such  stores: 
reduce  the  latency  and  update  budget  to  IS  ms.  compensate  for  latency  in  the  AIS,  or  reduce  the 
operational  performance.  The  first  of  these  options  is  considered  unreasonable  because  of  the 
design  complexity  that  would  be  forced  onto  the  AIS  and  the  target  sensing  systems.  The  second 
option  is  worth  consideration  as  this  would  transfer  a  task  from  the  expendable  store  to  the 
retained  AIS.  The  AIS  could  extrapolate  target  positions  through  knowledge  of  its  latency  and 
update  rates.  The  burden  would  be  increased  b^use  the  sensing  system  update  rate  would 
require  AIS  compensation  and  operational  performance  would  be  compromised  because  of  the  lack 
of  knowledge  of  the  store  induced  errors.  This  additional  AIS  sub  function  should  be  considered 
but  not  mandated.  The  third  option  may  be  inevitable  as  operational  performance  is  always 
related  to  the  capabilities  of  the  stores  carried.  Target  data  latency  and  update  rates  for  BVR 
stores  are  less  critical  than  with  short  range  stores.  Because  BVR  stores  lock  on  after  launch  the 
most  critical  target  update  is  the  last  one  received  after  launch.  This  update  will  be  succeeded  by 
a  long  gap  before  the  next  target  update.  This  is  because  this  next  update  is  dependent  on  the 
store  terminal  guidance  or  other  post  release  link.  The  effect  is  shown  in  figure  3.4  where  the 
longest  gap  between  updates  is  1 1 .5  seconds. 


Target  Position 
(y  axis  only)  in  meters 


FIGURE  3.4  Update  Rales  and  BVR  Stores 
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The  impact  of  this  update  delay  dominates  any  AIS  induced  error  in  fact  without  other  non-AIS 
mechanisms  the  target  would  probably  never  be  acquired,  it  can  be  concluded  than  BVR  stores 
place  less  stressing  performance  requirements  on  the  AIS  for  target  data.  Air  to  Ground  Stores 
can  be  considered  in  two  categories  for  target  data.  First  there  are  those  stores  (Maverick, 
Harpoon)  which  target  by  means  of  vector  information  from  the  aircraft.  Whether  they  are 
short  or  long  range  they  provide  essentially  the  same  requirements  for  data  latency  and  update 
rates  as  the  air  to  air  stores.  Secondly,  there  are  those  stores  which  intercept  targets  defined  in 
terms  of  mapping  coordinates.  For  these  stores  data  latency  can  be  ignored  for  the  target  data  as 
the  targets  do  not  move.  Data  Latency  does  become  of  extreme  concern  for  the  aircraft  data.  This 
is  considered  in  a  later  discussion.  Anti-Satellite  stores  provide  the  most  extreme  cases  for 
target  velocity  and  acceleration.  However,  because  the  target  velocities  and  accelerations  can  be 
precisely  defined,  compensation  for  long  delays  can  be  very  accurate.  Because  of  the  much  larger 
ranges  associated  with  such  stores  they  are  of  a  lock  or  after  launch  category  and  therefore  the 
AIS  target  data  latency  is  not  of  such  concern  as  the  AIS  aircraft  data  latency. 

3.2.3.2.4.2  Aircraft  Data  Latency  and  Update  Rates  fto  stores) 

AVS  Implementation:  AVS  performance  was  only  specified  for  one  type  of  Aircraft  Data  •  system 
time.  This  was  specified  to  be  transferred  with  a  maximum  error  of  2.5  ms.  To  achieve  this 
figure  several  design  features  were  required.  System  time  receipt  by  the  AVS  was  implemented 
as  a  high  priority  interrupt  to  existing  processes,  an  independent  timer  was  provided  to  store 
system  time,  the  AVS  corrected  the  system  time  value  for  known  errors  in  the  AVS  and  a  special 
mechanism  was  provided  in  the  MIL-STD-1SS3  Bus  Controller  to  insert  system  time 
automatically  into  messages.  Lastly,  MIL-STD-1760  messages  containing  system  time  were 
given  the  highest  priority  for  transfer.  This  AVS  implementation  is  considered  realistic  and  the 
design  required  not  unreasonable  given  the  importance  of  accurate  system  time.  Most  of  the  AVS 
stores  use  no  other  aircraft  data.  The  exception  is  AMRAAM  which,  although  not  a  full  MIL-STD- 
1760  store,  is  representative  enough  of  the  transfer  requiremer^ts.  No  performance 
requirements  were  specified  for  data  iatency  but  performance  goals  and  achievements  were 
similar  to  those  for  target  data  described  above. 

Other  Rationale:  Although  there  are  similarities  between  the  data  latency  requirements  for 
aircraft  data  and  target  data,  three  major  differences  require  separate  consideration.  These  are 
the  special  case  of  System  Time,  the  different  uses  of  aircraft  data  and  the  greater  accuracy  of 
availabtc  aircraft  data. 

a  System  Time  -  S/siem  Time  is  usually  taken  to  be  the  time  reference  for  all  data  in 
the  aircraft.  In  fact  there  may  be  difierent  system  times  but  any  combination  of  separate  data 
sets  in  a  function  must  first  ensure  a!l  c.a  related  to  a  common  time  reference.  System  Time  is 
usually  ta'^en  as  the  Aircraft  INS  system  time  and  it  is  easiest  if  every  other  system  and  store  on 
the  aircraft  is  synchronized  to  that  time.  System  Time  is  a  special  case  because  it  cannot  be  time 
tagged  for  correction  due  to  data  latency.  It  is  the  reference  used  by  stores  and  aircraft  to 
determine  time  tag  correctior's.  As  an  example  if  a  target  update  is  received  at  104  seconds  as 
angle  30,  angular  rate  20./second  and  time  tag  103  seconds  then  for  the  store  to  compensate  to 
the  true  target  position  st  1 04  seconds  it  must  have  an  accurate  system  time  reference  to 
determine  that  time  is  104  seconds.  In  practice  this  will  be  a  timer  updated  by  AIS  data  and  it  is 
the  accuracy  of  that  AIS  System  Timer  data  that  must  be  preserved.  Data  Latency  and  update 
rates  are  not  as  relevant  b^use  time  has  an  accurately  known  rate  of  change.  Because  System 
Time  will  be  used  in  computing  cH  time  tagged  data  corrections  its  received  accuracy  will  have  to 
be  higher  than  most  of  time  tags.  If  the  targeting  case  considered  above  is  analyzed,  time  tags 
were  used  to  correct  for  target  velocities  of  Mach  2  to  2.5.  For  the  System  Time  to  contribute 
minimally  to  further  errors  than  the  accuracy  would  havo  to  be  better  than  1/10  of  the 
maximum  timing  error  of  150  ms.  This  would  give  a  required  accuracy  of  15  ms.  For  the  case 
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of  an  inertially  guided  store  with  no  terntinal  guidance  then  a  Cumulative  Error  Probability 
(CEP)  of  30  meters  might  be  required.  If  released  at  Mach  1  then  this  would  correspond  to 
approximately  100  ms  error.  If  10%  of  that  error  is  budgeted  to  the  System  Time  than  a 
required  accuracy  of  10  ms  can  be  derived.  To  allow  for  all  cases  over  the  timeframe  of  an  AIS  a 
maximum  inaccuracy  of  5  ms  is  proposed  (100%  better  than  the  INS  store  case)  but  no  specific 
requirements  for  latency  or  update  rate  are  suggested  (provided  their  effects  are  compensated 
for). 


b.  Aircraft  Data  •  There  are  msny  data  types  listed  as  aircraft  data  in  the  June  1985 
Notice  1  Logicai  Design  but  the  Key  ones  relevant  to  data  latency  and  update  rates  are  those 
associated  with  identifying  the  store  position  in  an  inertial  frame.  This  requires  communicating 
to  the  store,  aircraft  position  and  velocity  data.  These  are  both  usually  known  accurately  by  the 
aircraft  but  will  change  during  the  time  ^iay  through  the  AIS.  The  store  will  be  able  to 
compensate  for  position  errors  by  use  of  time  tagged  data  but  will  not  be  able  to  correct  velocity 
data  until  the  store  INS  is  aligned  with  the  aircraft.  The  most  stressing  case  is  that  of  a  medium 
range  store  and  a  typical  case  might  be: 

Range;  36,000  meters  (22  miles) 

Speed:  Mach  2  (600  meters/sec) 

Max  error:  30  meters  (100ft) 

Alignment  time:  1  second  in  captive  flight  prior  to  release 

The  store  will  therefore  be  in  free  flight  for  1  minute,  which  is  too  short  a  time  for  INS  long¬ 
term  positional  drift  to  cause  errors  but  the  INS  velocity  error  at  release  must  be  less  than  30 
meters  a  minute.  Allowing  AIS  delays  of  10%,  this  figure  gives  the  velocity  error  as  0.05 
meters/second.  If  the  store  is  aligned  during  final  aircraft  approach  the  average  acceleration 
could  be  4g  (160  meters/sec^).  This  sets  the  first  approximation  for  maximum  time  delay  as: 

0.05/160  «  312  uS 

This  figure  is  impossible  to  achieve  so  two  compensating  factors  should  also  be  considered.  These 
are  the  ability  of  the  store  INS  to  use  its  own  sensed  accelerations  to  partially  correct  for  the 
aircraft  acceleration  and  also  the  ability  of  the  store  to  apply  a  Kalman  filter  to  successive  data 
updates  to  progressively  filter  out  errors.  Allowing  for  80%  compensation  by  time  tagging  and  a 
25%  error  reduction  by  Kalman  filtering  at  each  update  then  using  L  and  U  for  data  latency  and 
update  rate: 

160  X  0.2  X  L  X  (0.75)^  -  0.05  L  X  (0.75)^  -  1.56  ms 

The  table  below  lists  values  of  L  and  U  that  piovide  the  required  accuracy. 


1.  (mS) 

U  (H2) 

Velocity  Error  (m/s) 

1.56 

1 

0.05 

27.7 

1  0 

0.05 

50 

1  2 

0.05 

100 

14.5 

0.05 

200 

16.09 

0.05 

1000 

22.5 

0.05 

2076 

25 

0.05 
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These  figures  are  similar  but  less  stressing  than  those  derived  for  target  data.  For  longer  range 
stores  these  are  usually  aligned  prior  to  the  final  approach  phase  and  therefore  lower 
acceleration  and  longer  alignment  times  reduce  the  stress  on  the  data  timing  requirements.  The 
main  consideration  with  such  stores  is  removal  of  residual  acceleration  errors  caused  by  the 
uncertain  initial  alignment  with  the  gravity  vector.  These  errors  are  removed  through  a  process 
called  fine  alignment.  This  requires  updates  of  accurate  aircraft  velocity  data  at  between  0.02 
and  1  Hz  over  some  minutes. 

3.2.3.2.4.3  Data  Letencv  -  Design  Considerations  A  high  level  representation  of  the  AIS  data 
paths  is  given  in  figure  3.5.  Avionics  data  from  a  data  bus  (PI-Bus  or  other  form)  is  received 
by  the  AIS,  processed  and  then  regularly  output  to  a  store  via  a  MIL-STD-1553  Bus.  The  three 
separate  activities  are  shown  in  figure  3.6  with  the  build  up  to  data  latency  through  the  AIS 
being  caused  by  the  lack  of  synchronization  of  activities,  the  finite  time  to  process  data  and  the 
finite  time  between  updates.  The  AIS  processing  cycle  can  be  synchronized  to  the  avionics  update 
and  the  MIL-STD-1553  output  but  this  can  become  very  complex  when  many  data  types  are 
received  at  different  rates  or  the  avionics  or  stores  update  cycles  change  dynamically.  For  the 
store  update  cycle  to  be  effective  the  Avionics  update  cycle  and  the  AIS  processing  cycle  must  be 
at  least  as  fast.  Therefore  Update  Rate  impacts  are:  Avionics  Bus  Loading,  AIS  Processing  Power 
required,  and  AIS  Bus  Loading.  The  worst  case  data  latency  will  the  sum  of  the  avionics, 
processing  and  MIL-STD-1553  Bus  cycle  times.  Therefore  Data  Latency  impacts  are: 

a  Avionics  Bus  Loading 

b.  Processor  Power  required 

c.  Update  Raie;  made  up  of  Avionics  Bus  Loading,  Processor  Power,  and  AIS  Bus  Loading 

Clearly  obtaining  improvements  in  data  latency  will  have  about  twice  the  design  impact  as 
improving  the  update  rate  alone.  The  conclusion  drawn  is  that  data  latency  should  contribute 
approximately  twice  as  much  error  as  update  rate.  From  the  previous  requirements  for  target 
and  aircraft  data  this  would  be: 

Data  Type  Maximum  Latency  Minimum  Update  Rate 

Target  Data  100  ms  20  Hz 

Aircraft  Data  120  ms  15  Hz 

System  Time  10  ms* 

'Perceived  as  maximum  inaccuracy  of  received  data. 

3.2.3.2.4.4  Analog  Data  Latency 

AVS  Implementation:  No  performance  was  specified  for  analog  data  latency. 

Other  Rationale:  This  is  discussed  by  signal  type: 

a  HB1/HB2  -  These  signals  may  be  used  for  a  number  of  purposes  including  GPS  and 
Time  Correlation  Pulses  (TCP).  A  500  ns  latency  is  equivalent  to  a  150  meter  error  in 
navigation  data  but  this  would  only  occur  if  some  data  from  different  navigation  sources  did  not 
suffer  the  same  delay.  In  practice  this  is  not  the  case  and  is  tolerable.  500  ns  represents  an 
allowance  for  a  100  meter  cable  length  and  a  prewarning  of  1  us  for  TCP  from  aircraft 
transmitters. 

b.  HB3/HB4  -  The  majority  of  signals  for  these  interfaces  will  be  video  of  target  data.  A 
latency  of  20  ms  represents  one  frame  delay  through  video  format  converter  and  0.5®  error  in 
targeting  a  moving  target  with  25®/second  relative  angular  rate. 
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FIGURE  3.5  Data  Flow  through  the  AIS 
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FIGURE  3.6  Data  Cycles 
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3  2.3.3  Unique  to  Store  Formatting  (8.2.3.3]  The  rationale  was  provided  in  the  Appendix  A 
guidance  and  no  further  rationale  is  necessary. 

3  2.3.4  Recomputation  to  Store  Axes  (8.2.3.4]  The  rationale  was  provided  in  the  Appendix  A 
guidance  and  no  further  rationale  is  necessary. 

3  2.3.5  Interface  to  Store  [8.2.3.5] 

3.2.3.5.1  Analog  Network  [8.2.3.5.1) 

ISSUE;  What  Performance? 

AVS  Implementation;  The  AVS  implemented  a  highly  stressing  network  capacity.  This 
corresponded  to  that  specified  in  the  July  1983  draft  MIL  STD-1760A.  Although  successfully 
implemented  this  networking  effectively  mandated  a  centralized  network. 

Other  Rationale;  MIL-STD-1760  recommends  a  network  capacity  (reference  Figure  13  of 
MIL-STD-1760).  This  recommended  network  capacity,  although  less  than  that  of  the  AVS,  tends 
to  force  a  centralized  network  solution  to  avoid  a  significant  quantity  of  aircraft  high  bandwidth 
cabling.  Appendix  A  recommends  a  network  capacity  to  provide  for; 

a  One  store  at  a  time  to  be  aligned  using  GPS  data 

b.  Two  radar  active  stores  to  be  TCP  "blanked" 

c.  Two  stores  to  send  video  to  the  aircraft  at  a  time  (to  allow  two  stores  to  be 
simultaneously,  targeted  as  specified  in  (8.2.1 .1 .3.c]) 

Note  that,  as  shown  in  figure  3.7,  the  network  implementation  is  likely  to  be  only  marginally 
increased  in  complexity  if  ASI*ASI  paths  are  required  for  Type  A  signals. 

3.2.3.5.2  Release  Consent  (8.2.3.5.2) 

ISSUE;  What  performance? 

AVS  Implementation;  No  specific  Release  Consent  performance  was  specified  for  the  AVS. 

Other  Rationale;  MIL-STO'1760  Notice  3  has  mandated  Release  Consent  as  an  interlock  on  the 
majority  of  safety  critical  functions.  Store  designers  will  therefore  depend  on  high  integrity 
implementation  of  the  signal.  This  has  to  be  specified  as  both  obsolete  performance  and  the 
independence  of  Release  Consent  from  other  AiS  functions. 

3.2.4  Data  from  Store  [8.2.4] 

ISSUE;  What  performance? 

AVS  Implementation;  No  general  performance  for  data  from  stores  was  specified  for  the  AVS. 

Other  Rationale;  Except  where  data  from  stores  Is  routed  to  another  store  the  accuracy,  latency 
and  update  rate  performance  can  be  reduced  by  approximately  50%  of  that  for  data  to  stores. 

This  applies  even  though  it  is  unlikely  that  timetag/change  rate  compensation  can  be  applied  for 
data  from  stores. 
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FIGURE  3.7  Analog  Networks  (for  Type  A  signals) 


3.2.5  Store  Selection  (8.2.5] 

3.2.5.1  StaUon  Determination  (8.2.5.1] 

ISSUE:  What  performance? 

AVS  Implementation:  The  AVS  implemented  a  similar  algorithm  to  that  of  the  one  presented  in 
Appendix  A.  No  weapon  bays  were  considered.  This  implementation  enabled  a  simple,  reliable 
and  optimized  software  solution  of  selection  during  stressing  releases  (bombs). 

Other  Rationale:  The  selection  algorithm  is  the  same  as  the  release  algorithm  to  provide  the 
maximum  number  of  selected  and  ready  stores  at  the  best  locations  during  release.  This  is  true 
for  all  store  types.  Further  comments  related  to  the  stated  rules  are: 

a  (8.2.5. 1. a]  -  Obvious 

b.  (8.2.5.1.b)  •  See  [8.2.7.6] 

c.  (8.2.5.1.C]  •  Deployment  of  weapon  bays  causes  a  number  of  performance 
degradations  Including  aerodynamic  drag.  It  is  therefore  best  to  reduce  these  problems  by 
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exhausting  one  bay  before  opening  another.  The  position  with  pylon  mounted  stores  is  however 
much  different.  As  shown  in  figure  3.8  the  paths  followed  by  stores  after  release,  particularly 
bombs  can  be  unpredict^le  immediately  following  separation.  It  is  quite  posst)le  for  stores  to 
collide  unless  all  possible  measures  are  taken  to  avoid  adjacent  paths.  Such  measures  include 
avoidance  of  successive  releases  from  same  or  adjacent  stations. 

d  (8.2.5.1.d]  •  See  (8.2.5.1.C]  above 

e.  (8.2.5. 1.e]  ■  A  rule  to  minimize  potential  obscuring  of  the  target 

f.  (8.2.5.1.f]  •  A  default  rule  to  ensure  resolution  of  the  algorithm  where  two  or  more 
stores  equally  satisfy  the  previous  rules. 


3.2.5.2  Store  InHialization  Management  [8.2.5.2)  The  rationale  was  provided  in  the  Appendx 
A  guidance  and  no  further  rationale  is  necessary. 

3.2.5.3  Release  Package  Data  Retention 
ISSUE:  What  performance? 

AIS  Implementation:  Described  in  2.4.5.5. 

Other  Rationale:  Provision  of  a  minimum  of  eight  packages  provides  for  pre-selection  of 
sufficient  attack/defense  setting  options  to  preclude  the  need  for  complex  crew  operations  at 
planned  targets.  The  data  included  per  package  in  Appendix  A  allows  for  the  majority  of  data 
types  that  are  prebriefable. 
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3.2.6  Store  Annina/Fuzinq  (82.6]  No  further  rationale  is  required  for  those  aspects  affected 
by  MIL-STD-1760. 

3.2.7  Steffi  Rflleasfl  [8.2.7] 

No  further  rationale  is  required  for  those  aspects  affected  by  MIL-STO-1760.  Brief  rationale  is 
however  provided  below. 

[8.2  7.1]  Figure  3.9  shows  the  signals  and  internal  circuitry  of  a  typical  rack  (the  MAU-12). 
Connection  of  28  volts  to  either  EED  will  initiate  release  of  the  Store  provided  the  inflight  lock  is 
in  the  enable  position.  Connection  of  28  volts  to  either  the  Nose  or  Tail  Pure  signals  during  store 
relear  e  will  re  :i>>t  in  potential  arming  of  the  ejected  store  by  retention  on  the  rack  of  arming 
lanyards. 

(8.2.7.2]  Figure  3.10  Shows  a  number  of  simplified  weapon  bay  carried  stores.  In  bay  A  the 
store  must  not  be  released  until  after  the  bay  has  been  opened  and.  if  the  store  is  a  forward  firing 
store,  the  S  &  RE  doployed  beyond  the  bay  by  means  of  vertical  translation  devices.  Such  a 
deployed  S  &  RE  is  snown  for  bay  C.  In  bay  B  the  S  &  RE  is  not  deployed  but  is  instead  rotated  to 
allow  many  stores  to  be  ejected  through  the  same  bay  opening.  Should  the  store  shown  shaded  be 
ejected  than  an  aircraft  hazard  would  result.  The  MS  should  therefore  implement  high  integrity 
mechanisms  to  ensure  proper  bay  management. 

[8.2  7.3]  No  further  Rationale  required.  A  typical  sequence  of  events  is  shown  in  figure  3.1 1 . 

[82.7.4]  Separation  timings  have  to  be  accurate  to  3  ns  to  minimize  the  CEP.  For  a  non  guided 
bomb  release  3  ns  corresponds  to  i  meter  error  at  mach  1 .  Release  intervals  at  30  ns  allow  for 
high  density  deployment  of  stores  against  targets  even  at  high  attadk  velocities.  30  ms  pairs 
release  allows  for  10  bombs  to  be  released  in  balance  and  land  within  a  100  meter  area  at  a  mach 
0.6  release.  Note  that  the  MS  release  performance  is  dominated  by  dumb  bombs.  Smart  stores 
are  less  stressing  because  they  can  oornpensate  for  a  less  demanrfing  AIS  performance. 

[8.2  7.5]  No  further  rationale  required. 

[82.7.6]  Store  gone  status  has  to  be  determined  quickly  during  release  to  enable  rapid  releases 
without  violation  of  aircraft  balance.  Unfortunately  as  shown  in  figure  3.12  the  S  &  RE  return 
signals  are  likely  to  be  unstable  for  many  milliseoorxls  due  to  switch  contact  bourK^e.  Appendix  A 
states  that  3  of  5  signals  detected  chang^  is  a  firni  indication  of  store  gone.  This  also  avoids  the 
potential  hazard  of  only  monitoring  one  signal  (interlock)  which  could  tail  open  circuit  for  other 
reasorts. 

[8.2.7.7]  No  further  rationale  required. 

[8.2.7.8]  No  further  rationale  required. 

3.2.8  Store  Jettison  [82.8]  Store  jettison  as  considered  by  [8.2.8]  is  not  affected  by 
MIL-STD-1760.  No  further  rationale  is  therefore  given  mlditional  to  that  of  2.4.8  and  the 
Appenrfix  A  text. 

32.9  Inventory  [82.9]  No  further  rationale  required  as  this  function  is  not  affected  by 
MIL-STD-1760. 
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FIGURE  3.10  Stores  in  Weapon  Bays 


3-2.10  Crow  Interfaces  No  further  rationale  required  as  these  funoiic's  are  not  s’gnitlcantly 
affected  by  MIL-STD-1760.  Sec  also  2.4.10  and  3.2.2  2. 

3.2.11  Nuclear  Control  [8.2.11]  Rationale  for  the  Appendix  A  guidance  is  provided  in  the  type 
A  system  specification  CDRL  -  COOK. 

3.3  AIS  General  Performance  |8.3] 

3.3.1  E.(Dansion  Provision  [8.3.1] 

AVS  (nplementation;  No  specific  expansion  provision  was  specified  for  the  AVS. 

Other  Rationale:  Refer  to  [8.3.1. a]  and  (8.3.1. b)  to  relate  this  rationale: 

a  The  guidance  in  Appendix  A  provides  for  a  100%  increase  in  software  stored  and 
processed  to  allow  for  a  40%  increase  in  both  store  types  and  modes  of  usage  (  .4x1.4  »  1.96). 

b.  A  100%  spare  data  bus  capacity  is  specified  lo  match  the  processing,  jower  spare 
capacity. 

c.  A  25%  of  high  bandwidth,  discrete  and  power  wiring  is  specified  as  spare  to  allow  for 
a  proportional  increase  in  the  number  of  weapon  stations. 

d.  All  other  signals  have  only  10%  spare  capacity  as  these  i elate  to  discrete  signals  for 
critical  controls  and  communication  to  aircraft  systems  (for  example  the  engines).  This  is  not 
likely  to  noticeably  increase  during  the  aircraft  life. 

e.  A  50%  of  internal  data  bus  capacity  is  specified  unused  to  match  the  unused 
processing  power.  These  usually  increase  proportionally  with  each  other. 

f .  A  20%  of  central  equipment  module  space  and  power  consumption  is  specified  as 
unused  to  allow  for  the  extra  interfaces  to  support  the  potential  25%  increase  in  weapon  stations 
(see  c.  above). 

3.3.2  ReliabiliU  (8.3.2)  These  factors  are  not  significantly  affected  by  MIL  STD-1760. 
Rationale  is  therefore  generally  brief. 
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FIGURE  3.1 1  Typical  Separation  Event  Sequence 
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FIGURE  3.12  Hang  Up  Detection 


3.3.2. 1  Mean  Time  Between  Failure  tMTBFt  18.3.2.2] 

RATIONALE:  An  MTBF  of  1000  hours  is  specified,  as  this  effectively  sets  AIS  failures  as  a  very 
mirK)r  cause  of  projected  mission  failures,  while  not  imposing  too  stressing  a  requirement  on  AIS 
design.  It  is  necessary  to  consider  specifying  a  mission  point  because  otherwise  it  is  possible  to 
produce  a  system  that  appears  to  just  satisfy  the  requirements  while  in  fact  offering  either 
excessive  over  design  or  unacceptably  poor  performance  except  in  unrealistic  circumstances.  To 
explain  this  point  further  consider  figures  3.13,  3.14  and  3.15.  Figure  3.13  shows  an  AIS 
partitioned  in  an  abstract  sense  into  four  areas: 

Fully  redundant  and  full  Built  in  Test  -  Fully  redundant  and  no  Built  in  Test 

No  redundancy  and  full  Built  in  Test  •  No  redundancy  and  no  Built  in  Test 

If  the  system  has  90%  circuitry  redundant  (weighted  by  defect  probability)  and  98.5%  BIT 
coverage  then  parts  b.  and  d.  contribute  little  to  the  overall  defect  rate  because  they  comprise 
less  than  2%  of  the  circuitry  that  can  fall.  The  effect  of  c.  and  d.  on  the  success  performance  is 
dramatic.  Although  c.  is  fully  tested  OK  by  BIT  at  mission  start,  should  a  defect  occur  in  c.  the 
system  will  fail.  Since  d.  is  untested  by  BIT  a  defect  will  not  only  cause  system  failure  but  may 
have  occurred  before  in  any  of  the  hours  of  use  before  the  mission  started.  If  the  AIS  is  100% 
ground  tested  every  200  hours  then  there  will  be  an  average  of  100  hours  of  probably  defects  in 
d.  at  a  mission  start.  These  effects  are  shown  in  figure  3.14  where  d.  is  200  times  more  likely 
to  lead  to  mission  failure  than  a  even  though  a.  contributes  600  times  more  defects.  The  AIS 
should  therefore  have  both  a  high  degree  of  redundancy  and  BIT  to  avoid  a  high  failure  to  defect 
ratio.  This  is  difficult  to  specify  directly  and  as  shown  in  figure  3.15  cannot  be  specified 
without  consideration  of  hours  since  last  100%  test.  In  figure  3.15  an  example  system  with  no 
BIT  has  appalling  success  performance  after  100  hours  use.  but  appears  better  immediately 
after  a  100%  test. 
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3.3.2.2  Mean  Time  Between  Critical  Failure  <MTBCF)  (8.3.2.3] 


RATIONALE:  A  1  in  10^  hours  MTBCF  is  approximately  equal  to  one  critical  accident  per 
aircraft  type  in  20  years  (assuming  1000  aircraft  @  500  hours/year).  This  is  not  usually 
achieved  in  practice.  A  typically  specified  figure  for  the  airframe  itself  is  1  in  10^  years  (5 
acckJenls  per  year). 

3.3  2.3  Damage  Tolerance  [8.3.2.4]  The  rationale  was  provided  in  the  Appendix  A  guidance  and 
no  further  rationale  is  necessary. 


FULL  BIT .  NO  BIT 

FULL  REDUNDANCY  FULL  REDUNDANCY 


FIGURE  3.13  Mission  Success  Analysis 


3.3.3  Maintainability  (8.3.3]  These  factors  are  not  significantly  affected  by  MIL-STO-1760 
and  no  further  rationale  is  required  beyond  that  provided  in  the  type  A  system  specification 
CDRL-COOK. 


3.3.4  Volume/Mass  (8.3.4)  Same  discussion  as  above  in  paragraph  3.3.3. 

3.3.5  Environmental  Requirements  (8.3.5)  These  factors  are  not  significantly  affected  by 
MIL-STD-1760  and  no  further  rationale  is  required  beycnd  that  provided  in  the  type  A  system 
specification  CDRL-COOK. 

3.3.6  Miscellar^eous  (8.3.6)  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no 
further  rationale  is  necessary. 

3.4  Interfaces  (8.4) 


3.4.1 


(8.4.1) 


ISSUE:  What  performance  for  aircraft  supplies? 

RATIONALE:  A  strict  limit  on  allowod  voltage  drop  from  aircraft  power  supplies  is  specified 
because  otherwise  there  will  be  no  allowance  for  voltage  drops  across  the  AIS  connectors,  wiring 
and  switching  elements.  The  specified  voltages  allow  for  1 .5  volts  DC  and  2.5  volts  AC  drop 
across  the  AIS.  The  currents  and  overcurrents  specified  are  a  mapping  of  the  MIL-STD-1760 
ASI  in  current  performance  for  four  ASI  (see  (8.2.1.1.3.C])  allowing  for  20%  of  current  to  be 
consumed  by  the  AIS  with  a  safety  factor. 
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3.4.2  Diqiial  Interfaces  (8.4.2] 

ISSUE;  What  performance  for  aircraft  digital  interfaces.? 

AVS  Implementation:  The  AVS  implemented  a  MIL-STD-1553  data  interface  from  the  AIS  to  the 
avionics.  This  used  approximately  25%  of  available  data  bus  loading. 

Other  Rationale:  Given  the  predicted  data  bus  rates  and  addressing  required,  a  MIL-STD-1553 
data  interface  is  unlikely  to  be  adequate  for  future  AIS  -  alrcra^  interfaces.  The  predicted  data 
rates  and  addressing  rates  were  calculated  as  shown  below.  Two  High  Speed  Data  Bus  (HSDB) 
terminals  are  .specified  to  provide  for  redundant  AIS  processing  centers. 


Data  Rate-Items  Words/Second 

Target  data  for  4  active  targets  -16  words/target  @  20  Hz  bidirectior^al  2560 

Aircraft  data  -  30  words  (21  INS  anu  9  air  data)  (g>  15  Hz  450 

Radar  data  -  16  words  #  20  Hz  320 

Store  Status  for  64  stations  -  64  words  @  4  Hz  256 

Control  Prompts  -  16  words  (3>  20  Hz  256 

Miscellaneous  Data  -  256  words  ®  1  Hz  (average)  256 

Subtotal  4i62 

50%  Expansion  2081 

Total  6243 

Addressing  Item  words/second 

Data  for  16  targets  -  16  words/target  and  bidirectional  512 

Aircraft  Data  •  21  INS  and  9  Air  Data  words  3  0 

Radar  Data  -  16  words  1  6 

Data  Load/transfer  (dedicated  'subaddress')  -  32  words  bidirectional  64 

Aircraft/Store  alignment  -  64  stations  ®  6  words  384 

Release  Data  Packages  (3  ofO  -  56  words  each  424 

Control  Prompts  1  6 

Store  Stations  (64  stations)  -  1  word  64 

Fire  Control  Aircraft  Steering  data  -  1 6  words  1  6 

Inventory  (64  stations)  -  8  words  bidirectional  1 Q24 

Subtotal  2550 

100%  Expansion  2550 

Total  5100 


3.4.3  Discrete  Interfaces  (8.4.3|  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no 
further  rationale  is  necessary. 

3.4.4  Analoa  interfaces  (3.4.4) 

ISSUE:  What  AIS  -  aircraft  performance? 

RATIONALE:  The  performance  specified  in  Appendix  A  supports  the  networking  of  (8.2.3.5.1| 
while  also  providing  for  single  fault  immunity  of  each  interlace  type.  This  results  In  dual  1 .6 
GHz  interfaces. 

3.4.5  Connectors  [8.4.5]  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further 
rationale  is  necessary. 
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4.  RATIONALE  FOR  APPENDIX  A  SECTION  9 


Paragraphs  4.1  through  4.3  of  this  sectiort  provide  rationale  derived  from  the  AVS  and  other 
sources  to  support  the  guidance  given  in  paragraphs  9.2  through  9.4  of  Appendix  A.  Issue 
statements  and  subjects  have  bean  summarized.  When  rationale  was  supplied  in  the  guidance 
text,  further  rationale  is  not  supplied. 

4.1  AIS  Functional  ParlitioninQ 

4.1.1  Partitioning  of  External  Functions 

4. 1.1.1  High  Bandwidth  Signals  (9.2.2.1.11 

ISSUE;  How  should  High  Bandwidth  network  be  partitioned? 

RATIONALE;  This  issue  is  considered  in  more  detail  in  paragraph  10.1.1.1.1  of  Appendix  A  and 
the  rationale  is  provided  in  paragraph  5.1. 1.1  of  this  document. 

4.1. 1.2  MUX  Buses  (9.2.2.1.2) 

ISSUE;  How  should  the  MUX  Bus  and  its  control  be  partitioned? 

RATIONALE;  The  guidance  given  for  this  issue  results  from  addressing  the  more  detailed  issues 
discussed  in  the  paragraphs  of  10.1.2  in  Appendix  A.  Rationale  supporting  these  more  detailed 
issues  is  given  in  the  paragraphs  of  5.1.2  in  this  document. 

4.1. 1.3  Low  Bandwidth  (9.2.2.1.31 

ISSUE;  How  should  the  Low  Bandwidth  network  be  partitioned? 

RATIONALE;  This  issue  is  discussed  in  more  detail  in  paragraph  10.1.3.1.1  of  Appendix  A  and 
rationale  supporting  this  is  given  in  paragraph  5.1 .3.1  of  this  document. 

4. 1.1. 4  Release  Consent  (9.2.2.1.41 

ISSUE;  How  should  the  Release  Consent  function  be  partitioned? 

RATIONALE;  The  guidance  given  for  this  issue  results  from  addressing  the  more  detailed  issues 
discussed  in  the  paragraphs  of  10.1.4.1  of  Appendix  A.  Rationale  supporting  these  more  detailed 
issues  is  given  in  the  paragraphs  5. 1.4.1  through  5. 1.4. 3  of  this  document. 

4.1. 1.5  Inlerlock  (9.2,2.1.51 

ISSUE;  How  should  the  interlock  function  be  partitioned? 

RATIONALE;  This  issue  is  discussed  in  more  detail  in  paragraph  10.1.4.2.1  of  Appendix  A  and 
rationale  supporting  this  is  given  in  paragraph  5.1 .4.4  of  this  document. 

4. 1.1. 6  Structure  Ground  (9.2.2.1.61 

ISSUE;  How  should  the  Structure  Ground  function  be  partitioned? 
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RATIONALE;  This  issue  is  discussed  in  more  detail  in  paragraph  10.1 .4.4  of  Appendix  A  and 
rationale  supporling  this  is  given  in  paragraph  5.1 .4.8  of  this  document. 

4. 1.1. 7  Address  Discretes  (9.2.2.1.7] 

ISSUE;  How  should  the  address  determination  function  be  partitioned? 

RATIONALE;  The  guidance  giver  for  this  issue  results  from  addressing  the  more  detailed  issues 
discussed  in  paragraph  10.1.4.3.1  and  10.1.4.3.2  of  Appendix  A.  Rationale  supporting  these 
issues  is  given  in  paragraphs  5.1 .4.6  and  5.1. 4.7  of  this  document. 

4.1. 1.8  Power  [9.2.2.1.81 

ISSUE;  How  should  the  power  control  function  be  partitioned? 

RATIONALE;  The  guidance  given  for  this  issue  results  from  addressing  the  more  detailed  issues 
discussed  in  the  paragraphs  of  10.1.5  in  Appendix  A.  Rationale  supporting  these  more  detailed 
issues  is  given  in  paragraphs  5. 1.5.1  through  5. 1.5.9  of  this  document. 

4.1. 1.9  Store  Critical  State  [9.2.2.2] 

ISSUE;  Partitioning  of  store  critical  state  function. 

RATIONALE:  The  following  paragraphs  address  each  of  the  three  AIS  subfunctbns  of  the  store 
critical  state  function  in  turn: 

a  State  Command  This  is  associated  with  transmitting  data  to  the  store  using  the 
MIL<STD-1553  stores  bus  and  controlling  the  Release  Consent  signal  to  the  store.  The  control  of 
the  stores  bus  should  be  central  as  discussed  in  paragraph  9.2.2.1.2  of  Appendix  A  and  the  state 
command  subfunction  would  best  be  performed  locally  to  the  MUX  bus  control  function  therefore 
this  should  also  be  performed  centrally.  The  control  of  Release  Consent  is  also  best  performed 
centrally  although  the  physical  switching  of  this  signal  is  best  distributed  as  discussed  in 
paragraph  9.2.2.1.4  of  A^ndix  A. 

b.  State  Monitor  This  is  associated  with  receiving  data  from  the  store  using  the 
MIL-STO-1553  stores  bus.  The  control  of  this  bus  should  be  central  as  discussed  in  paragraph 
9.2.2.1 .2  of  Appendix  A  and  the  state  monitor  subfunction  would  best  be  performed  lorally  to  the 
MUX  bus.  therefore  this  subfunction  should  also  be  performed  centrally. 

c.  Power  SuDOhr  management  The  power  required  by  a  store  is  dependent  on  the  store 
type  and  the  store  state  which  is  required.  This  is  therefore  directly  related  to  the  state 
command  and  state  monHor  subfunctions  discussed  above  and  so  the  control  of  the  power  to  a 
store  would  best  be  performed  with  these  subfunctions,  that  is  centrally.  The  actual  physical 
switching  of  the  power  may  be  distributed,  as  discussed  in  paragraph  9.2.2. 1.8  of  Appendix  A. 

AVS  Implementation:  All  AIS  aspects  of  store  state  control  are  performed  within  the  SMS 
processor  in  the  central  Process  Control  Equipment  apart  from,  the  physical  switching  of  the 
power  and  Release  Consent  which  was  distr^ted  in  the  Store  Station  Equipments.  This  was 
considered  the  most  logicai  position  for  this  function  cs  the  SMS  processor  has  access  to 
information  of  all  inputs  that  affect  this  function. 

4.1.1.10  Data  to  Store  [9.22.3] 
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ISSUE:  Partitioning  of  Data  to  Store  function. 

RATIONALE:  The  following  paragraphs  address  each  of  the  three  AIS  subfunc^ions  of  the  Data  to 
Store  function  in  turn: 

a  Unique  to  Store  formatting  This  is  concerned  with  ensuring  the  data  transmitted  to 
the  store,  on  the  MIL-STD-t553  stores  bus.  is  in  the  correct  format.  This  subfunction  is 
therefore  closely  related  to  the  store  bus  control  function  and  would  best  be  performed  locally  to 
this  bus  control  function.  As  discussed  in  paragraph  9.2.2.1.2  of  Appendix  A.  the  bus  control 
function  should  be  performed  centrally,  therefore  the  unique  to  store  formatting  subfunction 
would  also  best  be  controlled  centrally. 

b.  Recomputation  to  store  axes  This  subfunction  is  also  concerned  with  ensuring  the  data 
transmitted  to  the  store  is  in  the  correct  format,  in  this  case  referenced  to  the  correct  axes 
system  as  required  by  the  store.  This  should  therefore  be  treated  in  the  same  way  as  the  unique 
to  store  formatting  and  should  be  provided  centrally  and  locally  tr  a  stores  bus  control 
function. 

c.  Interface  with  Store  Management  of  the  store  interface  signals  should  be  positioned 
such  that  this  subfurtction  has  access  to  all  the  information  which  could  affect  this  store 
interface,  such  as  inputs  from  other  avionics  equipment,  and  safety  critical  switches  such  as 
master  arm  and  the  trigger.  This  requirement  is  best  met  by  a  central  processor.  The 
partitioning  of  the  actual  control  circuitry  for  the  individual  signals  of  the  store  interface  is 
discussed  in  the  paragraph  9.2.2.1  in  Appendix  A. 

AVS  Implementation:  The  AIS  aspects  of  the  data  to  store  function  within  the  AVS  is  performed  in 
the  central  Process  Control  Equipment  (PCE).  The  Avionics  Processor  performs  much  of  the 
Unique  to  store  formatting  with  the  SMS  Processor  performing  the  management  of  the  store 
interface.  No  recomputation  to  store  axes  was  performed  as  none  of  the  stores  in  the  AVS 
inventory  required  this.  This  arrangement  worked  well  as  the  PCE  has  access  to  all  the  input 
information  which  could  affect  or  change  the  data  to  the  stores. 

4.1.1.11  Data  from  Store  (9.2.2.4] 

ISSUE:  Partitioning  of  Data  from  Store  function. 

RATIONALE:  The  following  paragraph  address  each  of  the  three  AIS  subfunctions  of  tho  Data  from 
Store  function  in  turn: 

a  Unique  to  User  formattino  This  is  concerned  with  ensuring  that  the  data  received 
from  the  store  is  in  the  correct  format  before  it  is  transferred  to  other  avionics  equipment.  This 
subfunction  is  therefore  closely  related  to  the  stores  bus  controller  function  and  would  best  be 
performed  locally  to  this.  As  discussed  in  paragraph  9.2.2.1 .2  of  Appendix  A,  the  bus  control 
function  should  be  performed  centrally  therefore  the  Unique  to  User  formatting  subfunction 
should  also  be  performed  centrally. 

b-  Recomoutation  to  User  axes  This  subfunction  is  also  concerned  with  ensurir^  the  data 
received  from  the  store  is  in  the  correct  format  to  be  transferred  to  other  avionic  equipments. 

In  this  case  the  particular  area  of  concern  Is  to  ensure  the  data  is  referenced  to  the  correct  axes 
system.  This  subfunction  is  therefore  similar  to  the  Unique  to  User  formatting  and  should  be 
performed  in  the  same  place,  that  is  centrally. 
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c.  Interface  with  Avionics  Most  of  the  actions  resulting  from  data  being  received  from 
the  store  are  concerned  with  passing  this  information  on,  in  whatever  form,  to  other  avionics 
equipment.  The  primary  method  of  transferring  this  information  to  other  avionics  equipment  is 
by  using  a  digital  data  bus.  The  AIS  will  contain  only  a  single  interface  (or  possibly  two 
interfaces)  to  this  avionics  digital  data  bus.  as  the  total  number  of  interfaces  to  this  bus  is 
probably  limited,  in  which  case  this  interface  with  Avionics  will  be  provided  in  a  central  unit. 

AVS  Implementation:  The  AIS  aspects  of  the  data  from  store  function  are  all  performed  in  the 
central  Process  Ck>ntrol  Equipment  (PCE).  The  Avionics  Processor  performs  most  of  the  Unique 
to  User  formatting  and  controlling  tho  interface  with  the  MIL-STD-1553  Avionics  bus.  The  SMS 
Processor  controls  the  transfer  of  data  from  the  Bus  Controller  processor  to  the  Avionics 
Processor.  No  recomputation  to  user  axes  is  performed  as  none  of  the  stores  in  the  AVS  loadout 
require  it.  This  arrangement  worked  well  as  all  elements  concerned  in  this  function  are 
performed  within  the  same  unit  thus  simplifying  the  overall  control  of  this  function. 

4.1.1.12  Store  Selection  [9.2.2.5] 

ISSUE;  Partitioning  of  Store  Selection  function. 

RATIONALE:  The  following  paragraphs  address  each  of  the  three  AIS  subfunctions  of  the  Store 
Selection  function  in  turn: 

a  Station  Determination  The  determination  of  which  stations  should  have  stores 
selected  is  dependent  on  many  different  factors  including  store  types  fitted  to  the  aircraft  and 
their  locations,  the  actual  state  of  the  store,  and  aircrew  selections.  As  all  this  varied 
information  has  to  be  available  before  a  valid  decision  can  be  made,  then  this  function  is  best 
performed  in  a  central  unit  which  has  access  to  all  the  information  that  is  required. 

b.  Store  Initialization  Management  The  initialization  requirements  are  at  least  in  pari 
specific  to  store  type  and  therefore  the  initialization  sequence  for  a  particular  station  is 
dependent  on  the  store  type  fitted  to  that  station.  The  information  defining  store  initialization 
sequences  would  best  be  stored  centrally  rather  than  having  to  be  duplicated  at  each  store  station. 
Similarly  the  management  function  requiring  this  information  would  best  be  located  centrally. 

c.  Release  Package  Data  Retention  The  information  for  release  packages  would  be 
transferred  to  the  AIS  using  a  digital  data  link  from  other  avionic  equipment.  This  information 
would  therefore  best  be  retained  locally  to  the  interface  to  this  avionics  data  link  which  will  be 
in  a  central  unit. 

AVS  Implementation:  The  AIS  aspects  of  the  store  selection  function  are  all  performed  in  the  SMS 
Processor  within  the  Process  Control  Equipment.  This  arrangement  works  well  as  the  SMS 
Processor  has  easy  access  to  all  the  information  required  to  perform  this  function. 

4.1.1.13  Store  Fuzing  (9.2.2.61 

ISSUE:  Partitioning  of  Store  Fuzing  function. 

RATIONALE:  The  following  paragraphs  address  each  of  the  two  AIS  subfundions  of  Store  Fuzing. 

a  Fuzing  Management  The  decision  of  which  stores  to  Fuze  and  how  to  fuze  them  is 
dependent  on  store  type,  stores  selected  and  inputs  from  the  aircrew.  This  means  that  the  best 
position  for  this  decision  to  be  made,  and  the  management  of  implementing  the  actions  decided 
upon,  is  in  a  central  unit  that  has  access  to  all  the  information  required.  The  signals  which 
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control  the  arming  solenoids  are  considered  safety  critical  and  as  such  the  physical  switching  of 
these  signals  should  be  partitioned  according  to  the  guidance  for  safety  critical  signals  given  in 
paragraph  10.2.1  of  Appendix  A. 

b.  Fuzing  Times  Computation  These  computations  are  dependent  on  store  type,  aircraft 
data  such  as  height,  velocity  and  target  data.  The  best  location  for  performing  this  computation, 
aixl  controlling  the  transfer  of  the  result  to  the  store,  is  in  a  central  unit  that  has  access  to  all 
the  information  required. 

AVS  Implementation:  The  management  of  the  fuzing  demands  are  performed  by  the  SMS 
Processor  in  the  Process  Control  Equipment,  using  the  MIL-STD-1553  Armaments  bus  to 
transmit  commands  to  the  Store  Station  Equipments  to  control  the  safety  critical  switches  for  the 
Arm  Mode  outputs.  This  arrangement  worked  well  as  the  SMS  Processor  had  access  to  all  the 
information  required  to  decide  which  signals  to  activate  and  when  they  should  be  activated.  None 
of  the  stores  fitted  to  the  AVS  required  Fuzing  Times  therefore  the  AVS  did  not  perform  any 
computations  associated  with  this. 

4.1.1.14  Store  Release  (9.2.2.71 

ISSUE:  Partitioning  of  Store  Release  Function. 

RATIONALE:  The  following  address  each  of  the  seven  AIS  subfunctions  of  Store  Release  in  turn: 

a.  Suspension  Equipment  Management  The  decision  of  which  suspension  Equipment 
signals  to  activate  and  when  to  activate  them  is  dependent  on  many  different  factors  including 
equipment  type,  store  type,  release  sequence,  and  aircrew  demands.  This  means  that  the  best 
position  for  this  decision  making  to  be  performed  is  in  a  central  unit  with  access  to  all  the 
relevant  information.  The  position  of  the  physical  switches  used  to  activate  the  suspension 
equipment  signals  may  be  distributed  but  these  should  be  controlled  from  the  central  decision 
making  unit. 

b.  Weapon  Bav  Management  This  is  similar  to  suspension  Equipment  Management  where 
the  physical  switches  to  activate  the  Weapon  Bay  signals  may  be  distributed  but  the  decision 
making  process  of  when  they  should  be  activated  should  be  performed  centrally. 

c.  Release  Management  The  decisions  concerned  with  if  and  when  a  release  should  take 
place  are  dependent  on  many  different  factors  therefore  this  should  be  located  in  a  central  unit 
with  access  to  all  the  relevant  information. 

d  Release  Timing  The  decisions  concerned  with  controlling  release  timing  are  dependent 
on  many  factors  such  as  store  type  and  position  and  aircrew  selections.  These  decisions  are 
therefore  best  performed  in  a  central  unit  with  access  to  all  the  relevant  information. 

e.  Bfilfiase  Seouence  Determination  The  decisions  concerned  with  determining  the 
release  sequence  is  dependent  on  many  factors  such  as  store  type,  position  and  status,  aircrew 
selection  and  aircraft  balance.  These  decisions  are  therefore  best  performed  in  a  central  unit 
with  access  to  all  the  relevant  information. 

f  •  Balance  Management  The  decisions  concerned  with  ensuring  aircraft  balance  is 
maintained  during  release  sequences  and  determining  how  release  sequences  should  be  modified  to 
maintain  airaaft  balance  Is  dependent  on  many  factors  including  store  type,  position  and  status. 
Release  sequence  and  Release  Timings.  These  decisions  are  therefore  best  performed  in  a  central 
unit  with  access  to  alt  the  relevant  information. 
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g.  Engine  Control  Assistance  The  decisions  associated  with  engine  control  assistance  are 
closely  associated  with  release  timing  and  so  should  be  performed  in  the  same  place  as  the  release 
timing  function,  that  is  in  a  central  unit. 

AVS  Implementation:  All  the  above  functions  relevant  to  the  AVS  are  performed  centrally  within 
the  Process  Control  Equipment  although  the  physical  switches  for  the  relevant  signals  are 
distributed.  All  the  decision  making  is  performed  in  the  SMS  Processor  which  has  access  to  all 
the  relevant  information.  This  simplifies  the  overall  control  of  this  information  as  it  is  ail 
contained  in  one  physical  unit  and  primarily  controlled  by  a  single  processor.  The  AVS  is  not 
required  to  perform  Engine  Control  Assistance  or  Weapon  Bay  management. 

4.1.1.15  Slflffl.  Jeitisan  (9.2.2.8I 

ISSUE:  Partitioning  of  Store  Jettison  function. 

RATIONALE:  The  following  paragraphs  address  each  of  the  three  AIS  subfunctions  of  Store 
Jettison  in  turn: 

a  Selective  Jettison  This  is  a  specialized  form  of  Store  Release  and  therefore  is  best 
performed  in  the  same  manner  as  Store  Release,  that  is  all  the  control  should  be  in  a  central  unit 
although  the  signal  switching  may  be  distributed. 

b.  Emergency  Jettison  This  is  similar  to  Selective  Jettison  and  therefore  should  be 
provided  centrally  although  signal  switching  may  be  distributed. 

c.  Store  Safe  Verification  This  is  dosely  associated  with  Fuzing  Management  (fiscussed 
in  4.1.1.13.a.  and  should  be  perfomted  in  the  same  location,  that  is  in  a  central  unit  although  the 
signal  switching  may  be  distributed. 

AVS  Implementation:  These  AIS  aspects  of  Store  Jettison  are  all  performed  in  the  Process 
Control  Equipment  (PCE).  Selective  Jettison  control  is  performed  by  the  SMS  Processor  as  is 
the  Store  Safe  Verification.  Emergency  Jettison  Control  is  also  performed  by  the  SMS  Processor 
with  a  separate  independent  back  up  hardware  Emergency  Jettison  controller  also  located  in  the 
PCE.  This  provides  the  higher  assurance  that  is  required  for  Emergency  Jettison  to  be 
performed  when  demanded.  This  arrangement  worked  well  as  it  minimized  the  additional 
hardware  and  software  required  to  provide  the  Store  Jettison  function  as  maximum  use  could  be 
made  of  hardware  and  software  provided  for  normal  release. 

4.1.1.16  tnyflfltfliy  I9.2.2.9; 

ISSUE:  Partitioning  of  Inventory  function. 

RATIONALE:  The  ktlbwing  paragraphs  address  the  two  AIS  subfunctions  of  Inventory  in  turn. 

a  Inventory  Conrirmaiion  This  function  ret^ires  access  to  the  defined  Inventory  Load, 
Store-on-Station  information.  Store  identification  information  from  MIL-STO-1760  stores, 
and  identification  information,  if  any,  from  existing  stores.  This  function  is  therefore  best 
performed  by  a  central  unit  with  access  to  all  this  information. 

b.  Inventory  Update  This  function  reqpiires  secure  storage  of  inventory  data  and  access 
to  information  from  the  Store  Selection,  Store  Release  and  Store  Jettison  functions  all  of  which 
should  be  provided  centrally.  This  function  is  therefore  best  performed  by  a  central  unit  with 


344 


access  to  all  the  relevant  information  and  provides  a  single  secure  data  base  for  inventory 
information. 

AVS  Implementation;  The  limited  loadout  of  the  AVS  and  the  restricted  weapon  types  that  can  be 
fitted  allows  the  AVS  to  create  the  inventory  from  store  on  station  information  and  store 
identification  information  rather  than  having  to  confirm  inventory  data  input  by  other  means. 
This  inventory  creation  and  S(A)se<^ent  inventory  update  is  performed  by  the  SMS  Processor  in 
the  Process  Control  Equ^ent  (PCE).  This  arrangement  worked  well  as  th^s  processor  had  easy 
access  to  all  the  relevant  information. 

4.1.1.17  Crew  Interface  (9.2.2.10] 

ISSUE:  Partitioning  of  Crew  Interface  functon. 

RATIONALE;  The  switches  associated  with  the  Critical  Controls  Interface,  the  only  AIS 
subfunction  of  Crew  Interfaces,  rteed  to  be  positioned  to  enable  easy  selection  by  the  relevant 
crew  member.  These  switches  are  used  as  inputs  to  many  of  the  other  centrally  controlled 
functions,  such  as  Store  Critical  State,  Store  Release  and  Store  Jettison.  These  switches  are 
therefore  best  monitored  centrally  in  the  unit  performing  these  other  functions. 

AVS  Implementation:  The  switches  for  the  Critical  Controls  Interface  are  provided  alongside  the 
Multi-Function  Display  which  simulates  the  crew  interface  for  the  AVS.  The  monitoring  of  these 
switches  is  performed  in  the  PCE.  This  was  considered  the  best  location  for  these  monitors  as 
they  form  a  key  part  of  many  of  the  functions  performed  by  the  PCE. 

4.1.1.18  Nuclear  Controls  19.2.2.11) 

ISSUE:  Partitioning  of  Nuclear  Controls  function. 

RATIONALE:  The  following  paragraphs  address  each  of  the  AIS  subfunctions  of  the  Nuclear 
Control  function  in  turn. 

a  S&RE  Management  This  is  similar  to  the  Suspension  Equipment  Management 
discussed  in  4.1.1.14  a.  with  the  addition  of  the  control  for  the  in  flight  reversible  lock  and 
should  be  treated  in  the  same  manner,  that  is  the  decision  making  process  of  nuclear  S&RE 
management  should  be  performed  in  a  central  unit  with  access  to  all  the  relevant  information 
although  the  physical  switches  used  to  activate  the  S&RE  signals  may  be  distributed. 

b.  Crew  Controls  This  is  similar  to  the  Critical  Controls  Interface  discussed  in  4.1.1.16 
and  should  be  treated  in  the  same  manner,  that  is  the  switches  need  to  be  (kstrftxited  to  allow  easy 
access  by  the  relevant  crew  member  with  the  nronitoring  being  performed  in  a  central  unit. 

c.  Crew  Displays  This  is  similar  to  the  Crew  Controls  above  with  the  actual  display 
being  distributed  to  allow  monitoring  by  the  relevant  crew  member  tut  the  control  of  the  display 
should  be  from  a  central  unit. 

4.1.1.19  Memory  Expansion  Provision  (9.2.2.12.1) 

ISSUE;  Where  should  expansion  capabilities  be  provided  within  the  AIS? 

RATIONALE;  The  most  Ikely  reason  for  change  to  the  AIS  is  to  enaWe  the  AIS  to  control  atoditional 
stores  or  the  same  stores  at  different  or  new  store  locations.  This  should  only  affect  the 
software  for  the  central  system  control  and  management  process<KS.  Adcfitional  spare  memory 
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should  be  provided  for  these  processors  to  enable  the  extra  software  required  to  control  these 
additional  stores,  to  be  easily  irKXMH<^rated  without  having  to  update  the  hatxfware. 

4.1. 1^0  Processing  Expansion  Provisioft  [92.Z^22] 

ISSUE:  Where  should  spare  processing  capacity  be  provided  within  the  AIS? 

RATIONALE:  The  rrxtst  Ukely  reason  for  change  to  the  AIS  is  to  enable  the  AIS  to  control  additional 
stores.  These  new  stores  may  require  adrfitionad  data  reformatting  or  computations  performed  on 
data  to  or  from  the  store.  Adcitional  processing  capacity  may  be  requireJ  to  perform  this  work 
but  this  should  only  affect  the  central  system  control  and  management  processors.  Thus,  spare 
processfog  capacity  should  be  provided  for  these  central  processors  to  enable  addhional  stores  to 
be  controlled  by  tira  system  without  having  to  update  the  hardware. 

4.1.1.21  Interfaces  Expansion  Provision  (9.2.2.12.31 

ISSUE:  Where  should  additional  store  interfoces  be  provided  within  the  AIS? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance. 

4.1.1.22  HflliabililiL  (9.2.2.131 
ISSUE:  Partitioning  of  Reliability. 

RATIONALE:  Some  ratiortale  was  provided  in  the  Appendix  A  guidance  arxl  more  detailed  rationale 
is  given  in  section  3  of  this  document. 

4.1.1.23  Maintainability  (9.2.2.141 
ISSUE:  Partitioning  of  Maintainability. 

RATIONALE:  More  detail  on  Built  in  Test  circuitry  is  given  in  paragraph  10.2.4  of  Appendix  A. 
Once  a  failure  has  been  detected  then  the  relevant  unit  wHI  be  identifi^  as  faulty.  The  faulty 
unit  will  then  be  exchanged  at  the  1st  maintenance  level  (organizational)  and  sent  to  the  2nd 
maintenance  level  (intermediate).  At  the  2nd  maintenance  level  there  must  be  some  method  of 
determining  tho  reason  for  the  particular  unit  being  identified  as  faulty.  To  allow  for  this  each 
unit  should  as  a  minimum  contain  some  form  of  non-volatile  storage  facility  to  record  the 
information  obtained  from  the  system  Built  in  Test  procedures  which  results  in  a  particular  unit 
being  identified  as  faulty. 

4.1.1.24  Volume/Mass  [9.2.2.15]  No  guidance  was  given. 

4.1.1.25  Environment  (9.2.2.16]  No  guidance  was  given. 

4.1.1 ’6  Power  Dissipation  (9.2.2.17.11  No  guidance  was  given. 

4.1.127  Power  Consumption  [9.2.2.17.2] 

ISSUE:  Effects  of  Power  Consumption  on  p»titior  'ng. 

RATIONALE:  The  rationale  was  provided  in  tiie  Appendbr  A  gindance. 
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4.1.2  Partitioning  cf  Iniflrnal  Pupcilons  (9-2.3] 

ISSUE;  Ho‘;y  should  the  AIS  system  designer  implement  internal  functions? 

RATIONALE:  Tt  .e  rationale  was  provided  in  the  Appendix  A  guidance. 

4.2  AIS  Internal  Interfaces  (9.3) 

ISSUE:  Specification  of  internal  interfaces. 

RATIONALE:  This  is  covered  in  the  rationale  for  the  more  detailed  aspects  of  internal  interfaces 
given  in  paragraphs  4.2.  i  through  4.2.5. 

4.2.1  Connectors  and  Cabling  (9.3.1] 


ISSUE:  How  should  the  AIS  system  designer  specify  cables  and  connectors? 

RATIONALE:  This  issue  is  considered  in  more  detail  in  section  10  of  Appendix  A  and  further 
rationale  supporting  the  guidance  given  is  to  be  found  in  the  following  paragraphs  ci  this 
document:  paragraphs  5.1.1.6  and  5.1. 1.7  for  High  Bandwidth  signals;  paragraphs  5.1 .3.6  and 
5  1.3.7  for  Low  Bandwidth  signals:  and  paragraphs  5. 1.5.5  and  5. 1.5.6  for  power. 

4.2.2  Power  Interfaces  [9-3.2] 

ISSUE:  How  should  the  AIS  system  designer  specify  power  interfaces? 

RATIONALE:  The  guidance  given  for  this  issue  results  from  addressing  the  more  detailed  issues 
discussed  in  the  paragraphs  of  10.1.5  of  Appendix  A.  Rationale  supporting  these  more  detailed 
issues  is  given  in  the  paragraphs  5.1 .5  of  this  document. 

4.2.3  Dicital  Interfaces  (9.3.3) 

ISSUE:  Specify  the  use  of  digital  transmission. 

RATIONALE:  The  guidance  given  for  this  issue  results  partly  from  addressing  the  more  detailed 
issues  discussed  in  paragraph  10. 1 .2  of  Apcvindix  A.  Rationale  supporting  these  more  detailed 
issues  are  given  in  paragraphs  5.1.2  of  this  viocument.  Figure  4.1  shows  examples  of  different 
architectures  for  digital  transfer  standards  that  ca?  he  used  within  the  AIS.  Example  A  shows  the 
recommended  architecture.  Figure  4.2  illustrates  the  different  methods  of  partitioning  a  bus, 
that  is  Horizontal  partitioning  and  Vertical  partitioning. 

4.2.4  Discrete  Interfaces  [9.3.4] 

ISSUE:  Specify  the  use  of  discrete  signals. 

RATIONALE:  The  use  of  discrete  signals  associated  with  the  Release  Consent  output  is  discussed  in 
detail  in  paragraph  10.1.4.1.3  of  Appendix  A  and  in  paragraph  5.1 .4.3  of  this  document.  Similar 
rationale  applies  to  all  other  safety  critical  signals  within  the  AIS.  Figure  4.3  shows  a  typical 
arrangement  lor  discrete  interlocks  required  between  a  central  Process  Control  Equipment 
(PCE)  and  a  remote  Store  Station  Equipment  (SSE). 
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4  2.5  Analog  Signals  (9.3.5) 

ISSUE:  Specify  use  of  internal  analog  signals. 

RATIONALE:  The  guidance  given  for  this  issue  results  from  addressing  the  more  detailed  Issues 
discussed  in  paragraphs  10.1.1  and  10.1.3  of  Appendix  A.  Rationale  supporting  these  more 
detailed  issues  is  given  in  paragraphs  5.1.1  and  5.1.3  of  this  document. 


a.  Common  MIL-STD-1553  Bus 


b.  Use  0*  other  data  bus  within  AIS 


c.  Use  of  Fiber  Optic  Bus  within  AIS  with  local  MlL-STD-1553  Buses 
FIGURE  4.1  Different  Digital  Transfer  Standards  for  AIS 
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4.3  System  Design  Documentation  [9.4] 

ISSUE:  How  should  MIL-STD-490  be  used  to  record  the  system  design? 
RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance. 


a.  Horizontal  partitioning 


b.  Vertical  partitioning 
FIGURE  42  Partitioning  of  Buses 
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FIGURE  4.3  Direct  Discrete  Safety  Interlocks 


5.  RATIONALE  FOR  APPENDIX  A  SECTION  10 


Paragraphs  5.1  and  5.2  of  this  section  provide  rationale  derived  from  the  AVS  and  other  sources 
to  support  the  guidance  given  in  paragraphs  10.1  and  10.2  of  Appendix  A.  Issue  statements  and 
subjects  have  been  summarized.  Where  rationale  was  suppN^  in  the  guidance  text,  and  further 
provision  considered  superfluous,  then  extra  rationale  is  not  supplied. 

5.1  MILrSTD-1760A  Implementation  Guidance 

5.1.1  High  Bandwidth  Issues 

5. 1.1.1  Centralized  or  Distributed  (10.1.1.1.1) 

ISSUE:  Should  the  High  Bandwidth  Network  be  centralized  or  distributed? 

RATIONALE:  The  issue  of  whether  the  High  Bandwidth  Network  should  be  centralized  or 
distributed  cannot  be  divorced  from  some  of  the  other  issues  to  be  discussed.  As  stated  in  the 
guidance  there  are  several  major  factors  to  consider  before  deciding  on  the  topology  to  be  used. 
These  are  discussed  in  more  detail  below. 

a  VSWR  The  VSWR  is  affected  among  other  things,  by  the  technology  to  be  used,  the  type 
of  switch  elements  to  be  employed  and  the  connectors  to  be  used.  Use  of  FDM  technology  will 
make  it  easier  to  meet  the  VSWR  figures  for  the  type  A  signals  as  the  High  Bandwidth  lines  from 
each  AS!  can  be  terminated  locally  at  the  associated  Store  Station  Equipments  before  the  signals 
are  encoded  onto  the  FDM  network.  If  switch  technology  is  used  then  the  whole  network  has  to  be 
considered,  as  any  discontinuity  in  the  impedance  of  the  signal  path  will  affect  the  overall  VSWR 
seen  at  a  particular  AS1.  A  discontinuity  in  the  impedance  of  a  signal  path  will  be  caused  by 
every  switch  element  and  every  connector  in  the  signal  path.  This  will  affect  the  choice  of  which 
switch  elements  and  connector  types  to  use  for  these  High  Bandwidth  sigi.als  and  the  total 
numbers  of  these  that  can  be  used  in  any  signal  path.  This  is  of  particular  concern  for  the  higher 
frequency  type  B  signals.  If  a  centralized  network  is  used  then  specialized  multi  pole  RF  relays 
can  be  employed  which  will  greatly  reduce  the  number  of  switch  elements  and  connectors  in  a 
signal  path  making  it  easier  to  ensure  the  VSWR  characteristics  of  every  signal  path  will  meet 
the  requirements  of  MIL-STD-1760. 

b.  Amount  of  Aircraft  Wiring  The  amount  of  aircraft  wiring  required  for  the  High 
Bandwidth  Network  is  dependent  on  the  following  factors: 

1.  Technology  to  be  used:  Using  FDM  technology  will  greatly  reduce  the  amount 
of  aircraft  wiring  required  to  implement  the  High  Bandwidth  Network.  Figure  5.1  shows  the 
wiring  required  tor  a  typical  5  pylon  aircraft  using  FDM  technology.  However  the  cost  of  using 
FDM  technology  is  high  compared  with  relays  and  the  large  size  of  the  circuitry  in  a  store  station 
equipment  required  to  irnplement  the  FDM  network  has  to  be  weighed  against  the  saving  in 
aircraft  wiring  which  vill  be  achieved. 

2 .  Number  of  Netv/ork  paths  required:  The  minimum  number  of  paths  required 
by  MIL-STD-1760  is  three,  that  is  one  path  for  type  B  signals,  one  path  for  50  ohm  type  A 
signals  and  ono  path  for  75  ohm  type  A  signals.  MIL-STD-1760  however  recommends  that  the 
aircraft  provides  7  paths  (one  path  for  type  B  signals,  three  paths  for  50  ohm  type  signals  and 
three  paths  for  75  ohm  type  A  signals),  and  particular  aircraft  implementation  may  require 
more  interconnection  paths  to  be  provided. 
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FIGURE  5.1  Typical  Wiring  Required  for  FDM  Approsch 
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3.  Number  and  Position  of  ASl:  This  will  vary  greatly  between  aircraft.  For  a 
small  fighter  type  aircraft  there  may  be  a  total  of  eight  ASl,  three  on  each  wing  and  two  on  the 
Fuselage.  For  a  large  bomber  type  aircraft  then  many  more  ASl  will  be  provided  many  of  which 
may  be  in  Weapon  Bays. 

4.  Class  of  Interface:  A  full  Class  I  interface  requires  four  High  Bandwidth 
signals  at  an  ASl  whereas  the  class  ll  interface  has  the  requirement  for  HB2  and  HB4  deleted  and 
so  only  requires  two  High  Bandwidth  signals  at  an  ASl. 

c.  Broken  Networks  The  easiest  way  to  implement  a  distributed  system  is  to  ‘daisy 
chain*  the  High  Bandwidth  network  paths  from  one  store  station  equipment  (SSE)  to  the  next 
along  the  wing  or  down  the  fuselage.  If  one  of  these  SSE  can  be  removed  then  the  network  is 
broken  and  those  SSE  further  down  the  chain  are  also  disconnected  from  the  High  Bandwidth 
network.  This  can  be  overcome  by  adding  non  removable  junction  boxes  in  the  aircraft  wiring 
to  ‘T’  off  the  High  Bandwidth  signals  for  a  removable  SSE  but  this  greatly  complicates  the 
aircraft  wiring.  A  centralized  system  does  not  have  this  problem  as  the  wiring  from  all  ASl  goes 
direct  to  a  central  Equipment. 

AVS  Implementation:  The  AVS  implements  a  centralized  system  where  the  four  High  Bandwidth 
signals  from  each  ASl  are  wired  directly  to  a  centrally  located  Signal  Network  Equipment  (SNE). 
The  SNE  implements  10  interconnection  paths,  one  path  for  type  B  signals,  five  paths  for  50 
ohm  type  A  signals  and  four  paths  for  75  ohm  type  A  signals.  The  AVS  worked  well,  performing 
all  the  functions  required  of  the  High  Bandwidth  network  simply  and  easily. 

Test  and  Evaluation;  The  AVS  Evaluation  Process  Report  and  Summary  (Document  Number 
182/70/57),  indicates  that  those  parts  of  the  AVS  associated  with  High  Bandwidth  Networking 
could  be  used  for  an  on-aircraft  AEIS.  The  MIL-STD-1760  Test  Process  Report  2  (Document 
Number  182/70/24),  shows  that  the  AVS  met  all  the  requirements  of  MIL-STD-1760 
associated  with  High  Bandwidth  Signals.  However,  during  the  testing  associated  with  this  it  was 
found  that  a  high  level  of  crosstalk  existed  between  the  different  High  Bandwidth  Signal  lines. 
There  are  no  requirements  in  MIL-STD-1760  concerning  crosstalk  or  interference:  therefore, 
the  AVS  is  compliant  with  the  standard,  however  the  level  of  interference  seen  may  cause 
problems  in  an  on-aircraft  AEIS.  The  MIL-STD-1760  Evaluation  Process  Report  (Document 
Number  182/70/12),  indicates  that  all  the  aspects  of  the  High  Bandwidth  Requirements 
evaluated  were  acceptable  for  a  flight  standard  AEIS. 

5.1. 1.2  Switched  or  FDM  Technology  (10.1.1.1.2] 

ISSUE:  Should  the  High  Bandwidth  Network  use  switched  or  FDM  Technology? 

RATIONALE:  The  rationale  for  this  is  provided  in  the  Appendix  A  guidance  and  in  paragraph 
5. 1.1.1  above  and  no  further  rationale  is  necessary. 

5.1. 1.3  Shared  usaoe  (10.1.1.1.3) 

ISSUE:  Could  the  High  Bandwidth  Network  be  used  for  other  functions? 

RATIONALE;  Certain  existing  stores,  such  as  Maverick,  require  the  transfer  of  analog  signals 
between  the  store  and  aircraft  systems.  As  MIL-STD-1760  requires  that  networks  be  provided 
to  transfer  High  Bandwidth  signals  from  ASl  to  aircraft  then  these  MIL-STO-1760  Networks 
may  be  used  to  transfer  the  analog  signals  from  the  existing  non  1760  stores.  Before  this  is  done 
the  designer  must  consider  the  following  areas: 
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a  Network  terminations  The  MIL-STO'1760  High  Bandwidth  network  may  provide 
matched  impedance  terminations  for  those  signals  not  selected  for  transfer  over  the  High 
Bandwidth  network.  If  signals  from  existing  stores  are  to  be  routed  onto  the  High  Bandwidth 
network  they  may  have  to  drive  into  these  matched  terminations,  in  which  case  the  designer  must 
be  sure  that  the  store  will  not  be  affected  or  damaged  if  this  happens. 

b.  VSWR  If  signals  from  existing  non  1760  stores  are  to  be  routed  onto  the  High 
Bandwidth  network  additional  switching  elements  may  have  to  be  introduced.  As  discussed  in 
paragraph  5.1. 1.1  above  any  additional  switch  elements  will  affect  the  VSWR  of  the  network  and 
this  will  have  to  be  allowed  for  when  ensurirtg  that  the  High  Bandwidth  network  meets  the  VSWR 
requirements  of  MIL-STD-1760.  The  benefits  of  being  able  to  use  the  High  Bandwidth  network 
for  existing  stores  are:  reduced  aircraft  wiring  and  reduced  circuitry  within  equipments. 

Test  and  Evaluation:  The  MIL-STD-1760  Evaluation  Process  addressed  this  question  in  Report 
1,  Issue  13  (Document  Number  182/70/12).  and  concluded  that  the  High  Bandwidth  network 
could  be  used  for  non  1760  signals. 

5.1.1.4  Switching  elements  (or  Type.  B  skinals  [10.1.1.2.1] 

ISSUE:  What  type  of  switching  elements  should  be  used  for  type  B  signals? 

RATIONALE:  The  rationale  for  this  is  provided  in  the  Appendix  A  guidance  and  in  paragraph 
5. 1.1.1  above  and  no  further  rationale  is  necessary. 

5.1.1.5  Switching  elements  for  Tvoe  A  signals  [10.1. 12.2] 

ISSUE:  What  type  of  switching  elements  should  be  used  for  Type  A  signals? 

/ 

RATIONALE:  As  the  frequency  for  Type  A  signals  is  limited  to  a  maximum  of  20  MHz  it  become/^ 
easier  to  meet  the  VSWR  and  attenuation  requirements  of  MIL-STD-1760  compared  with  the/ 
Type  B  signals.  The  transfer  characteristics  for  MIL-R-39016  signal  relays  are  acceptable  to 
be  used  in  the  High  Bandwidth  network  (or  transferring  Type  A  signals  and  these  relays  are 
relatively  small  and  inexpensive.  The  characteristics  of  semiconductor  switches  would  not  be 
acceptable  to  allow  the  use  of  these  switches  in  a  High  Bandwidth  network  as  they  would  introduce 
excessive  attenuation  or  will  be  excessively  large. 

5.1. 1.6  Connectors  [10.1.1.2.3] 

ISSUE:  What  type  of  connectors  should  be  used  for  High  Bandwi'kh  signals? 

RATIONALE:  As  discussed  in  paragraph  5.1. 1.1  the  conn.xtc  s  :  v’  in  a  signal  path  will  cause  a 
discontinuity  of  the  impedance  of  the  path  and  thus  affect  th**  oveiu<  /SWR  seen  at  an  ASI.  This 
effect  is  particularly  important  for  the  Type  B  signals  whi.h  h&  s  frequency  components  as 
high  as  1 .6  GHz.  For  these  signals,  connectors  or  oon'acts  sncu  used  which  have  a 
characteristic  impedance  of  50  ohms  and  will  not  int  oduia  sigi  incant  discontinuity  of 
impedance.  For  Type  A  signals  the  maximum  frequency  component  is  20  MHz  which  means  the 
effects  of  impedance  discontinuities  are  not  as  great  as  for  the  Type  B  signals,  but  they  can  still 
have  significant  effects  on  the  VSWR  of  the  Type  A  signals.  The  connectors  or  contacts  used  for 
all  the  High  Bandwidth  signals  should  ensure  continued  overall  saeening  of  the  signal  lines  to 
reduce  interlerence  on  other  signal  lines  which  could  be  caused  by  the  high  frequency  signals  on 
the  High  Bandwidth  lines.  Figure  5.2  summarizes  the  recommendations  for  what  connectors  or 
contacts  to  use  for  the  High  Bandwidth  signals. 
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HB1 


HB2 


HB3 


Separate  MIL-C-39012  or  similar 
Connections  for  each  Signal 

HB4 


a.  Preferred 


Separate  MIL*C*39012  connector  for  HB1 
Coaxial  contacts  in  MIL-C>38999  Shell 
for  HB2,  HB3  and  HB4 


b.  Acceptable 


Coaxial  contacts  in  MIL>C-38999  Shell 
for  HB1.  HB2,  HB3  and  HB4 


c.  Non-preferred 


Coaxial  contacts  for  signal  and  screen  in 
MIL-C-38999  Shell  for  HB1,  HB2,  HB3  and  HB4 


d.  Unacceptable 


FIGURE  5.2  High  Bandwidth  Signal  Connectors 


5.1.1.7  Cabling  (10.1.1.2.41 

ISSUE;  What  type  of  cables  should  be  used  for  High  Bandwidth  signals? 

RATIONALE;  The  rationale  is  provided  in  the  Appendix  A  guidance  and  also  in  Paragraph  6  of 
MIL-STD-1760  and  no  further  rationale  is  necessary. 

5.1.2  MlL-STD-1553  Issues 

5.1.2.1  Local  or  Aircraft  Bus  [10.1.2.1.1] 

ISSUE;  Should  the  ASI  bus  be  a  local  bus  or  part  of  a  common  aircraft  bus? 
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RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  The  AVS  implements  a  common  aircraft  bus  for  all  the  ASI  provided.  A 
local  bus  is  generated  within  the  Carriage  Store  Equipment  (CSE)  to  provide  a  separate 
MIL-STD-1 553  bus  to  the  CSSI.  The  use  of  a  common  bus  worked  well  and  did  not  cause  any 
problems.  The  experience  with  the  CSE  shows  that  to  provide  separate  local  buses  greatly  to 
the  complexity  of  the  control  software  and  also  the  circuitry  required  to  implement  a  separate, 
albeit  simple,  bus  controller  in  the  CSE  was  very  significant  and  would  increase  the  size  of 
electronics  required  in  a  store  station  equipment  by  30-40%. 

5.1. 2.2  Single  or  Multiple  Buses  [10.1.2.1.2] 

ISSUE:  Should  single  or  multiple  buses  be  used  for  the  stores  bus? 

RATIONALE:  The  basic  level  of  activity  on  the  stores  bus,  in  terms  of  message  transfers,  is 
relatively  low  with  bursts  of  greater  activity  occurring  when  a  change  of  store  state  is  being 
demand^  or  when  store  releases  are  taking  place.  Inaeasing  the  number  of  Remote  Terminals 
on  this  bus  will  increase  the  basic  level  of  activity  but  this  will  still  remain  relatively  low.  The 
relative  size  of  the  periods  of  high  activity  for  store  state  changes  will  not  increase,  if  additional 
remote  terminals  are  added,  as  this  will  not  affect  the  basic  philosophy  that  only  requires  the 
release  of  one  or  possibly  two  stores  simultaneously.  All  other  store  state  changes  can  be  time 
multiplexed  to  spread,  and  sc  restrict,  the  level  of  activity.  The  electrical  loading  on  the  bus 
will  be  affected  by  the  number  of  remote  terminals  on  the  bus.  However,  there  should  be  enough 
tolerance  in  the  voltage  levels  specified  by  MiL-STD-1553  to  ensure  a  minimum  voltage  of  1.4 
V  p-p  at  the  ASI  as  specified  in  MIL-STD-1760  especially  if  low  loss  cable,  such  as  Trompeter 
TWC-78-2,  is  used.  The  minimum  output  voltage  lor  a  transmitter  allowed  by 
MIL-ST0-1553B  is  18V  p-p  (when  driving  into  a  70  ohm  load).  For  a  bus  with  30  Remote 
Terminals  presenting  the  maximum  load  impedance  then  a  typical  voltage  of  3.0V  p-p  would  be 
expected  at  the  ASI.  With  a  single  shorted  stub,  as  allowed  for  in  MIL-STD-1553,  this  would 
reduce  the  voltages  at  the  ASI  to  2.4V  p-p  typically.  This  still  allows  a  large  margin  for  further 
voltage  drops  due  to  the  attenuation  in  long  lengths  of  cable. 

AVS  ImplemetKation:  The  AVS  implements  an  armaments  bus  which  controls  5  ASIs  and  can  have 
a  total  of  12  Remote  Terminals  connected.  The  total  length  of  wiring  between  Transmitter  and 
ASI  can  be  18m.  The  maximum  bus  activity  was  measured  to  be  101.5  transmissions  per  second 
which  equates  to  less  than  7%  loading.  The  typical  voltage  seen  at  an  ASI  was  4.1V  p-p  which  is 
well  above  the  minimum  allowed. 

Test  and  Evaluation:  The  AVS  Evaluation  process  found  that  ail  aspects  of  the  MIL-STD-1553 
bus,  that  were  analyzed,  were  representative  of  an  AEIS  for  a  small  aircraft  (see  Document 
Number  182/70/57).  Report  Number  22  (Document  Number  182/70/45),  addresses 
particular  aspects  of  MIL-STO-1553  bus  including  issue  4  which  measured  the  bus  loading 
figures  quot^  above.  The  electrical  loading  aspects  of  the  MIL-STD-1553  bus  in  the  AVS  was 
addressed  in  both  the  MIL-STD-1 760  Test  Process,  see  Report  3  (Document  Number 
182/70.'49),  and  the  MIL-STD-1760  Evaluation  Process  Report  3  (Document  Number 
182/70/28).  The  typical  ASI  voltc.ge  figures  quoted  above  were  derived  from  these  documents. 

5.1. 2.3  snaiel  Use  (10.1.2.1.3; 

ISSUE;  Should  the  stores  bus  be  combined  with  other  aircraft  buses? 
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RATIONALE:  The  Stores  bus  lias  a  requirement  to  transfer  safety  critical  data  as  specified  in 
MIL-STO-1760.  The  remote  units  within  the  AIS,  partiojlarty  Store  Station  Equipment, 
require  safety  critical  information  to  be  passed  to  them.  This  information  could  be  arranged  in 
the  same  form  as  that  specified  for  stores  in  MIL-STD'1760.  If  this  were  done  then  it  would  be 
a  simple  matter  to  use  the  same  MlL-STD-1553  bus  to  transfer  safety  critical  and  other  data  to 
both  stores  and  remote  AIS  equipments.  This  has  the  advantage  that  only  one  safety  critical  bus 
controller  is  required  within  the  AIS  thus  saving  space  and  reducing  costs.  MIL  STO-1760 
defines  particular  formats  and  particular  subaddress  and  word  positions  for  safety  critical  data. 

If  non-AIS  equipments  were  on  the  same  bus  as  MIL-STD-1760  stores  then  these  equipments 
may  use  these  particular  word  positions  and  subarktresses  for  non-critical  information.  If  this 
happens  then  the  design  of  a  safety  criticai  bus  controllei,  that  meets  the  specified  performance 
in  MIL-STD-1760,  becomes  very  complex  if  not  impossible.  For  this  reason  it  is  undesirable  to 
allow  non-AIS  equipment  to  use  the  same  bus  as  MIL-STD-1760  stores. 

AVS  Implementation:  The  AVS  uses  the  same  bus.  Armaments  bus,  to  control  both  stores  and 
equipments  within  the  system.  The  data  formats  and  positions  for  the  AVS  equipments  were 
chosen  to  be  similar  to  those  specified  in  MIL-STD-1760.  This  simplified  the  control  software 
as  the  same  subroutines  could  be  used  for  both  stores  and  AVS  equipments  especially  in  the  safety 
critical  control  area.  Savings  were  also  made  in  the  hardware,  as  only  one  bus  controller  was 
required,  and  aircraft  wiring  was  reduced,  as  only  one  bus  was  required. 

5.1. 2.4  Linear  Bus  or  Other  Topolopy  [10.1.2.1.4) 

ISSUE:  What  topology  should  be  used  for  the  stores  bus? 

RATIONALE:  The  purpose  of  having  a  dual  redundant  bus  is  that  if  one  bus  gets  damaged  then  data 
can  still  be  transferred  on  the  other  bus.  To  maximize  the  usefulness  of  this,  the  two  buses 
should  be  physically  separated  to  reduce  the  probability  that  a  single  area  of  damage  can  affect 
both  buses.  In  many  types  of  aircraft  the  physical  construction  of  the  wings,  especially  H  they 
contain  fuel  tanks,  means  that  there  is  only  limited  space  for  cable  runs  that  are  physically 
separated  by  more  than  a  few  inches.  In  these  aircraft,  if  a  linear  bus  is  used,  then  the  two  buses 
would  be  physically  dose  to  each  other  for  much  of  the  v«ng  length  thus  increasing  the 
probability  that  a  single  area  of  battle  damage  coukJ  affect  both  buses.  To  overcome  this  a  starred 
bus  approach  could  be  adopted  such  that  the  actual  buses  are  restricted  to  the  fuselage  and  are 
physically  separated,  such  as  one  on  the  port  side  and  one  on  the  starboard  side.  Separate  stubs 
are  then  tsrf^en  from  both  these  buses  for  each  remote  terminal  position  in  the  wings.  This 
means  that  the  wings  will  onfy  contain  stub  wiring,  albeit  for  both  buses,  so  that  at  worst  a 
single  area  of  battle  damage  can  only  effect  the  stub  wiring  which  would  only  disrupt  particui2V 
terminals  and  not  the  bus  as  a  whole. 

5.1.2.5  Impact  of  Critical  signals  |10.1.2.2) 

ISSUE:  Impact  of  critical  data  transfer  on  the  stores  bus. 

RATIONALE:  The  rationale  for  this  issue  is  provided  in  the  Appendix  A  guidance  and  also  in 
paragraph  5.2. 2. 

5.1. 2.6  Hardware/Software  partitioning  [10.1.2.3] 

ISSUE:  How  should  Bus  Control  function  be  partitioned? 

RATIONALE:  To  be  able  to  demonstrate  that  the  critical  probaWlity  associated  with  the  mission 
store  critical  and  authority  words  has  been  met  there  needs  to  be  a  (Nearly  defined  relationship 
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between  these  data  words  and  the  safety  critical  input  demands  (such  as  master  arm  and  trigger). 
This  relationship  is  best  demonstrated  by  direct  hardware  interlr^s  similar  to  those  suggested 
in  paragraph  1 0.2.2  of  Appendix  A  for  the  chticai  authority  code  generation.  The  iniermessage 
gap  requirements  will  affect  the  decision  as  to  which  areas  of  the  bus  controller  should  be 
implemented  by  dedicated  hardware  and  which  areas  implemented  by  a  processor.  The  shorter 
the  intermessage  gap  the  more  attractive  a  dedicated  hardware  solution  is  for  the  areas  associated 
with  data  transfer.  At  this  level  there  are  many  alternatives  and  the  best  solution  for  a 
particutar  application  must  be  determined  by  the  designer  having  considered  ail  the 
requirements. 

5.1 .2.7  Qoea  circuit  Stubs  (10.1. 2.4) 

ISSUE:  What  effect  does  open  circuit  stubs  have  on  the  design  of  the  stores  bus? 

RATIONALE:  Orrce  a  store  is  released,  any  activity  on  the  MIL-STD-1553  stores  bus  will  cause 
radiations  from  the  exposed  umbilical  connector.  To  prevent  this  from  occurring,  the  stub  to  the 
ASl  needs  to  be  isolated  following  store  release.  Figure  10.9  in  Appendix  A  shows  three  methods 
for  achieving  this.  Methods  A  and  B  isolate  the  stub  using  relays  within  a  local  Store  Station 
Equipment  (SSE).  The  relay  is  controlled  by  commands  received  by  the  SSE  over  the  MIL-STD- 
1553  bus.  Method  C  isolates  the  ASl  by  controlling  the  stub  with  a  separate  Bus  Controller. 
When  the  store  has  been  released  the  bus  controller  associated  with  that  store  is  disabled.  The 
use  of  separate  bus  controllers  is  not  recommended  because  of  the  additional  circuitry  required 
for  this  approach,  see  paragraph  5.1 .2.1 . 

5.1.3  Low  Bandwidth  Issues 

5.1.3.1  Centralized  cr  distributed  (10.1.3.1.1) 

ISSUE:  Should  the  Low  Bandwidth  network  be  centralized  or  distributed. 

RATIONALE:  There  are  three  main  areas  to  consider  before  deciding  whether  a  centralized  or 
distributed  approach  is  most  appropriate. 

a  Amount  of  aircraft  wiring  This  is  primarily  dependent  on  the  number  of  network 
paths  to  be  provided  for  Low  Bandwidth  signals.  MIL-STD-1760  recommends  a  single  network 
path  although  particular  aircraft  implementations  may  require  rTX>re.  From  figure  10.10  in 
Appendix  A  it  can  be  seen  that  a  centralized  approach  requires  more  aircraft  wiring  then  a 
distributed  network  for  a  single  path.  As  more  paths  are  added  then  a  centralized  network 
becomes  more  attractive  in  terms  of  amount  of  aircraft  wiring. 

b.  Broken  Networks  This  is  similar  to  the  problem  described  in  paragraph  5.1.1 .1  for 
High  Bandwidth  Networks  where,  if  the  network  was  implemented  in  a  ’daisy  chain,'  then 
removal  of  an  SSE  will  break  the  chain  and  disconnect  other  ASIs  from  the  Low  Bandwidth 
network.  Adding  junction  boxes  in  the  aircraft  wiring,  to  T’  off  the  Low  Bandwklth  signal  to 
removable  SSE,  is  possible  but  this  greatly  complicates  the  aircraft  wiring.  A  centralized 
network  does  not  have  this  problem. 

c.  Similarity  with  High  Bandwidth  Network  A  neater  design  may  result  if  all  the 
analogue  signals  were  switched  in  the  same  places.  Provisions  would  already  have  been  made  for 
the  High  Bandwidth  network  to  ensure  interference  to  or  from  the  High  Ban^idth  signals  is 
minimized.  The  same  type  of  provisions  may  be  needed  for  the  Low  Bandwidth  signals,  so 
grouping  the  Low  Banr^kfth  signal  with  the  High  Bandwidth  senate  would  minimize  the 
additional  provisions  necessary  to  reduce  Interference  associated  with  the  Low  Bandwkfth  signal. 
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AVS  Implemeniation:  The  Low  Bandwvidth  network  in  the  AVS  is  implemented  centrally  in  the 
same  place  as  the  High  Bandwidth  networks,  that  is  within  the  Signal  Network  Equipments.  No 
particular  problems  were  found  with  this  implementation  and  the  Low  Bandwidth  network 
performed  as  required. 

Test  and  Evaluation;  The  AVS  Evaluation  Process.  Report  26  (Document  Number  182/70/48), 
found  that  the  implementation  of  the  Low  Bandwidth  network  in  the  AVS  could  be  used  in  an  on- 
aircraft  AEIS.  The  MIL-STO-1760  Test  Process  Report  4  (Document  Number  182/70/25), 
found  that  the  AVS  implemented  ail  the  requirements  of  MIL-STD-1760  associated  with  Low 
Bandwidth  signals. 

5.1. 3.2  Technology  [10.1.3.1.2] 

ISSUE:  What  technology  should  be  used  for  the  Low  Bandwidth  network? 

RATIONALE;  The  use  of  FDM  technology  might  be  attractive  if  this  is  to  be  used  for  implementing 
the  High  Bandwidth  Type  A  signal  networking.  However,  MIL-STD-1760  requires  that  the  Low 
Bandwidth  signals  are  able  to  pass  signals  of  •fi2V  to  -12V  and  frequeiKins  between  DC  and  50 
kHz.  FDM  networks  are  not  able  to  transfer  information  about  DC  signals  so  this  type  of 
technology  cannot  be  used  for  the  Low  Bandwidth  Network. 

5.1 .3.3  Shared  Usage  [10.1.3.1.3] 

ISSUE;  Could  the  Low  Bandwidth  network  be  used  for  other  functions? 

RATIONALE;  Certain  existing  stores,  such  as  Sidewirxler,  require  the  transfer  of  audio  signals 
between  the  store  arvj  airaaft  systems.  As  M'L-STD-1760  requires  that  a  network  be  provided 
to  transfer  Low  Bandwidth  signals  from  ASl  to  aircraft  then  this  network  may  be  used  to  transfer 
the  audio  signals  from  existing  non-1 760  stores.  This  could  be  easily  accomrrKxJated  by 
providing  additional  switching  elements  onto  the  Low  Bandwidth  network. 

AVS  Implementation;  The  AVS  uses  the  Low  Bandwidth  network  to  transfer  the  audio  signals  from 
Sidewinder  missiles  to  other  aircraft  systems.  No  problems  were  encountered  with  the  Low 
Bandwidth  network  meeting  the  requirements  of  MIL-STD-1760  or  with  the  control  of 
Sidewinder  missiles  including  the  routing  of  the  audio  signals  to  other  aircraft  systems. 

Test  and  Evaluation;  The  MIL-STD-1760  Evaluation  Process  addressed  this  question  in  issue  6 
of  Report  2  (Document  Number  182/70/14),  and  concluded  that  the  Low  Bandwidth  network 
may  be  used  for  non-1760  signals. 

5.1. 3.4  Impact  of  rxjtential  use  as  Low  Speed  Data  Bus  [10.1.3.1.4] 

ISSUE;  Affects  on  Low  Bandwidth  network  from  potential  use  as  Low  Speed  Data  Bus. 

RATIONALE:  A  data  bus  system  would  normally  use  'square  wave'  type  signals.  To  obtain 
reasonably  good  transitions  on  the  waveforr'  then  the  network  must  be  capifole  of  passing 
frequenci^  at  least  9  tintes  the  bit  rate  of  the  data  bos.  This  means  that  if  the  bandwidth  of  the 
network  is  limited  to  50  kHz  then  a  low  speed  data  bus  using  this  network  would  be  limited  to  a 
maximum  rate  of  5000  bits  per  second.  Increasing  the  bandwidth  of  the  network  to  1  MHz  would 
allow  a  data  bus  with  bit  rates  up  to  100,000  bits  per  second  to  be  used. 


359 


AVS  implementation:  The  Low  Bandwidth  netwoik  in  the  AVS  was  designed  to  allow  signals 
between  DC  and  l  MHz  to  be  transfened.  This  was  achieved  by  choosing  switch  elements  cap^>le 
of  transfemng  signals  within  this  extended  frequency  range  and  had  no  other  effect  on  the  AVS 
design.  Th'>  AVS  stil!  met  ail  the  requirements  of  MIL-STD-1760  associated  with  Low  Bandwidth 
signals  and  >vas  shown  to  be  capable  of  transferring  signals  of  up  to  1  MHz. 

Tesr  arKJ  Evaluation:  The  AVS  Evaluation  Pmcess  demonstrated  that  the  AVS  was  capable  of 
transferring  sig*tals  of  at  least  300  kHz  with  attenuations  below  0.1  dB,  see  issue  3  of  Report  26 
(Document  Nvmber  182/70/48). 

5.1. 3.5  Switching  Elements  [10.1.3.2] 

ISSUE:  What  type  o*  switching  elements  should  be  used  for  Low  Bandwidth  signals? 

RATIONALE:  Semiconductor  switches  of  comparable  size  to  MIL-R'39016  relays  would 
introduce  significant  series  impedance  into  the  Low  Bandwidth  signals  lines  which  could  cause 
severe  degradation  or  attenuation  of  the  signals  dependent  on  the  driving  and  receiving  circuits. 
MIL-R-39016  relays  would  have  little  effect  on  the  signal  quality  over  the  frequency  range  of 
the  Low  Bandwidth  network. 

AVS  Implementation:  The  AVS  uses  MIL-R-39016  relays  as  the  switch  elements  in  the  Low 
Bandwidth  network.  Ttiese  have  no  detect^>ie  effect  on  the  quality  of  signals  being  transferred 
over  the  Low  Bandwidth  network. 

Test  and  Evaluation:  The  AVS  Evaluation  Process  concluded  that  the  implementation  of  the  Low 
Bandwidth  network  was  acceptable  for  an  on-aircraft  AEIS,  see  Report  26  (Document  Number 
182/70/48).  The  MIL-STD-1760  Test  Process  found  that  the  AVS  compli^  with  all  the  Low 
Bandwidth  requirements  of  MIL-STD-1760.  see  Report  4  (Document  Number  182/70/25). 

5.1 .3.6  Connectors  (10.1.3.3.1) 

ISSUE:  What  type  of  connectors  should  be  used  for  Low  Bandwidth  signals? 

RATIONALE:  The  connectors  or  contacts  used  for  all  the  Low  Bandwidth  signals  should  ensure 
continued  overall  screening  of  the  signal  lines  to  reduce  interference  both  to  other  signal  lines 
which  could  be  caused  by  the  analogue  signals  on  the  Low  Bandwidth  network  and  to  the  Low 
Bandwidth  line  due  to  noise  generated  by  other  signal  or  pcwer  lines.  Figure  5.3  summarizes  the 
recommendations  for  what  connectors  or  contacts  should  be  used  for  the  Low  Bandwidth  network. 

5.1. 3.7  Cabling  [10.1.3.3.2] 

ISSUE:  What  type  of  cable  should  be  used  for  Low  Bandwidth  signals? 

RATI(^4ALE:  The  cabKng  used  for  Low  Bandwidth  signals  should  erasure  continual  overall 
screening  for  the  signal  fines  to  reduce  the  interference  both  to  other  signal  lines  which  could  be 
caused  by  the  analog  signals  on  the  Low  Bandwidth  network  artd  to  the  Low  Bandwidth  sign^  itself 
due  to  noise  generated  by  other  signal  or  power  lines.  Use  of  Twinaxial  or  Triax'ial  cable  will 
errsure  the  continuity  of  the  signal  screening  whereas  use  of  coaxial  cables  will  introrkrce  some 
break  in  the  overall  screening  of  the  signals. 
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b.  Non-preferred 

FIGURE  5.3  Low  Bandwidth  Signal  Connectors 


5.1.4  Discrete  signal  issues 

5.14.1  Release  Consent  switching  LocaUpn  (10.1.4.1.1) 

ISSUE:  Where  should  the  switching  elements  for  Release  Consent  be  located. 

RATIONALE;  As  Release  Consent  can  be  used  to  enable  safety  cntical  functions  then  great  care 
must  be  taken  to  reduce  the  possibility  that  this  signal  ccjid  be  unintentionally  activated.  One 
possible  cause  for  this  signal  to  be  inadvertently  activated  is  by  electromagnetic  pick  up  in  the 
aircraft  wiring.  To  reduce  the  susceptibility  of  this  signal  to  electromagnetic  pick  up,  the  length 
of  wiring  between  the  ASI  and  tlie  final  switching  element  of  the  Release  Consent  signal  should  be 
minimized.  This  can  be  achieved  by  ensuring  this  final  switching  element  is  located  in  an 
equipment  'ocal  to  the  ASI. 

A  VS  Implementation:  The  final  switching  elements  for  the  Release  Consent  Signal  is  located  in  the 
Store  Station  Equipment  associated  with  the  particular  ASI  being  controlled.  No  problems  have 
bjen  found  with  this  signal  tx-ii.;;  unintentionally  activated  due  to  pick  up  in  the  wiring. 

5.1. •1.2  Release  Consent  Switching  Circuit  Design  (10.1.4.1.2j 

’3SUE:  Guidance  <or  design  cf  Release  Consent  switching  circuits. 

RATIUNALE;  As  Release  Consent  can  be  used  to  enable  safety  cntica!  functions  within  a  store  then 
it  is  ccnsidered  as  a  safety  critical  signal  ana  all  the  guidance  on  safety  critical  switching  given 
in  paragraph  10.2.1  of  Appendix  A  applies  to  this  signal.  Some  Built-in-Test  and  monitoring 
ci'cjits  for  safety  critical  signals  require  a  pull  down  resistor  on  the  output  concerned.  The 
value  of  this  resistor  may  be  as  low  as  IK  ohm.  NiiL-STD-17€0  now  states  that  the  isolation 
bf'tween  Re'ease  Consent  signals  at  ditlerent  ASIs  must  be  greater  then  100k  ohm.  This  means 
that  if  pull  down  resistors  are  to  be  used  on  tfie  Release  Consent  output  then  each  must  be  greater 
t  .an  50K  otiiii  to  comply  with  this  isolation  requirement. 
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AVS  Irriplementation:  The  AVS  provided  five  switch  elements  in  the  Release  consent  output  path. 
This  is  considered  excessive  as  this  large  number  of  switch  elements  increases  the  probability  of 
this  signal  failing  with  no  significant  increase  in  the  safety  of  the  circuit.  The  monitoring 
circuit  of  Release  Consent  used  5K  ohm  puli  down  resistors  on  the  output  which  means  that  the 
AVS  does  not  comply  with  the  isolation  requirements  in  MIL-STD-1760A. 

5.1 .4.3  Internal  Information  Transfer  for  Release  Consent  [10.1.4.1.3] 

ISSUE;  How  does  Release  Consent  affect  internal  AIS  information  transfer? 

RATIONALE:  As  Release  Consent  is  considered  as  a  safety  critical  signal  there  is  a  need  to  be  able 
to  demonstrate  the  safety  of  the  Release  Consent  switching  circuits.  This  is  best  done  if  a  clearly 
denned  relationship  exists  between  the  Release  Consent  output  and  a  release  demand  from  the 
crew  selectable  switches,  such  as  the  Weapon  Release,  Trigger.  Selective  Jettison  and  Emergency 
Jettison  switches.  This  can  be  achieved  by  providing  discrete  signals  to  each  Store  Station 
Equipment  to  directly  control  one  of  the  switch  elements  in  the  Release  Consent  output  line. 

These  discrete  signals  are  only  activated  on  selection  cf  one  of  the  above  switches. 

5. 1.4.4  Monitoring  Location  for  Uiterlock  (10.1.4.2.1) 

ISSUE:  Where  should  the  Interlock  monitoring  circuitry  be  located? 

RATIONALE;  If  the  interlock  signal  is  monitored  locally  to  the  ASI  in  the  associated  Store  Station 
Equipment  then  the  result  can  be  transferred  to  other  units  using  the  internal  AIS  data  bus.  This 
will  ni.nimize  the  aircraft  wiring  associated  with  the  Interlock  signal,  as  deriirated  wires  are 
only  required  between  the  ASI  and  associated  SSE,  the  data  bus  alread>  being  provided  for  other 
uses.  However,  the  Interlock  signal  may  be  used  as  a  store  present  indicator  and  could  be  used  to 
disable  the  power  ou^uts  to  the  ASI  to  *deadface*  the  connector.  If  this  is  the  case  then  locating 
the  Interlock  monitoring  circuits  close  to  the  switch  elements  controlling  the  power  to  the  ASI 
means  that  the  power  outputs  can  be  disabled  immediately  the  Interlock  signal  indicales  store 
absent,  other.vise  delays  will  be  introduced  as  the  state  of  the  Interlock  signal  will  have  to 
transferred  over  the  data  bus. 

AVS  Implementation:  The  Interlock  monitoring  circuits  in  the  AVS  are  located  in  the  same  units 
as  the  power  switching  elements  associated  w'.n  the  particular  ASI  connector,  that  is  the 
primary  Interlock  monitors  are  located  in  the  Store  Station  Equipment  associated  with  the 
particular  ASI,  the  Auxiliary  Interlock  monitors  are  in  the  Auxiliary  Power  Switch  which 
contains  all  the  relays  controlling  the  Auxiliary  Power  outputs. 

5.1 .4.5  Circuitry  for  Interlock  (10.1.4.2.2} 

ISSUE:  What  guidance  can  be  given  for  the  designs  of  the  Interlock  circuitry? 

RATIONALE;  There  is  no  requirement  in  MIL  STD-1760  for  the  aircraft  to  use  the  Interlock 
signal,  however  it  is  a  convenient  signal  to  assist  in  determining  store  presence.  The  aircraft 
must  provide  other  means  of  determining  store  presence  as  MIL-STO-1760  states  that  the 
Interlock  interface  shall  not  be  used  as  the  sole  criteria  for  functions  which  could  result  in  an 
unsafe  condition  if  Interlock  circuit  fails  open.  If  the  aircraft  does  use  the  Interlock  interface 
for  ary  time  critical  functions,  such  as  to  help  determine  time  of  store  release  during  a  firing 
sequence,  then  the  designer  must  ensure  that  the  interlock  monitoring  circuit  does  net  introduce 
excessive  time  delays. 
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5.1. 4.5  Fixed  or  variable  Address  discretes  (10.1.4.3.1] 

ISSUE:  Should  the  Address  discretbS  have  fixed  or  variable  value? 

RATIONALE:  If  a  Store  was  allocated  an  incorrect  Remote  Terminal  address  then  that  store  could 
receive  safety  critical  information  transmitted  to  a  different  store,  or  similar  store  at  a 
different  location.  This  could  result  in  the  incorrectly  addressed  store  achieving  an  unsafe  state 
or  even  being  unintentionally  released.  If  the  state  of  the  address  discretes  can  be  varied  it  would 
be  difficult  to  show  that  a  store  cannot  be  allocated  an  incorrect  address,  especially  under  fault 
conditions.  Fixed  addresses  determined  by  hardwire  links  have  a  very  low  probability  of  failure 
and  are  therefore  considered  far  safer  for  determining  addresses  of  Remote  Terminals  capable  of 
receiving  safety  critical  information  over  the  bus. 

AVS  Implementation:  The  AVS  uses  fixed  addresses  determined  by  hardwire  links  for  all  Remote 
Terminal  address  discretes.  Faults  in  the  address  discrete  lines  were  immediately  detected 
before  any  safety  hazards  could  occur. 

5.1. 4.7  Address  determined  at  ASI  or  Equipment  (10.1.4.3.2] 

ISSUE:  Where  should  the  RT  Address  of  an  ASI  be  determined? 

RATIONALE:  If  the  RT  address  is  determined  within  a  removable,  interchangeable  structure, 
such  as  a  pylon,  then  there  is  a  possibility  that  the  pylon  coukJ  be  installed  at  the  wrong  location. 
This  could  result  in  the  address  of  two  stores  on  the  aircraft  being  swapped  or  both  stores  having 
the  same  address.  If  this  happened  then  there  is  the  possibility  that  stores  are  released  in  a 
wrong,  unsafe,  sequence  or  that  two  stores  are  released  simultaneously.  Therefore  the  address 
determination  circuitry  should  always  be  fitted  in  the  main  aircraft  structure  that  is  not 
removable. 

5. 1.4. 8  Structure  Ground  (10.1.4.4) 

ISSUE:  What  guidance  can  be  given  for  the  Structure  Ground  signals? 

RATIONALE:  MIL-STD-1760A  states  that  "Structure  Ground  shall  provide  an  electrical 
connection  between  aircraft  arxJ  store  structures  to  minimize  shock  hazards  to  personnel  as 
required  by  MIL-B-5087.  This  circuit  shall  not  be  used  as  a  signal  or  power  return  path."  The 
current  carrying  capability  of  the  Structure  Ground  lines  specified  in  MIL-STD-’760  is  not 
large  enough  to  be  ^able  of  carrying  the  hign  currents  than  can  be  generated  by  lightning 
strikes.  This  capability  must  be  provided  by  other  means  like  an  overall  screen  on  the  umbilical 
cable. 

AVS  Implementation:  The  Structure  ground  signal  for  each  ASI  is  bonded  directly  to  a  ground 
bonding  point  located  dose  to  the  appropriate  ASI.  This  provides  the  low  impedance  path  as 
required  by  MIL-B-5087. 

Test  and  Evaluation:  MIL-STD-t760  Test  Process  Report  6  (Document  Number  182/70/20), 
shows  that  the  AVS  complies  with  the  structure  ground  ■'equirements  of  MIL-STD-t760A.  The 
MIL-STD  1760  Evaluation  Process  Report  4  (Document  Number  182/70/28),  shows  that 
these  requirements  of  MiL-STD-1760A  are  reasonable  for  an  on-aircraft  AEIS. 

5.1.5  Power  Issues  (to.1.5] 

S.t.5.1  Oftnlralized  or  distributed  switching  (10.1.5.1. tj 
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ISSUE;  Should  the  power  switching  circuitry  be  centralized  or  distributed? 

RATIONALE;  MIL-STD-1760  states  that  the  application  of  28V  DC  Power  2  may  cause  the  safety 
of  the  store  to  be  degraded  so  this  signal  should  be  treated  as  a  safety  critical  supply.  Therefore 
as  many  of  the  recommendations  for  safety  critical  signals  should  be  applied  to  this  line  as  are 
practically  possible.  This  includes  providing  the  final  switching  element  as  close  to  the  ASI  as 
possible.  Thus  a  distributed  system  is  preferred  for  28V  DC  power  2  switching.  To  minimize 
aircraft  wiring  associated  with  28V  DC  the  switching  of  28V  DC  Power  1  should  also  be 
distributed.  This  enables  single  28V  DC  power  cables  to  be  routed  to  a  store  station  Equipment 
(SSE)  where  this  power  could  then  be  switched  locally  to  provide  the  28V  DC  Power  1  and  28V 
DC  Pov.'er  2  lines  to  the  ASI  as  well  as  being  used  for  internal  SSE  power.  Otherwise  a!  least 
three  separate  sets  of  28V  DC  Power  wiring  are  required  to  each  store  station.  Similarly 
reductions  in  aircraft  wiring  may  be  achieved  if  115V  AC  power  switching  were  distributed 
especially  to  store  stations  where  two  or  more  ASI  are  provided.  There  may  be  problems  in  the 
Store  Station  Equipment  if  there  is  limited  space  available,  as  the  size  of  the  switching  elements 
required  for  these  power  lines  is  relatively  targe,  if  there  is  a  problem  with  space  in  the  area  of 
the  ASI  then  some  or  all  of  the  switch  elements  associated  with  1 1 5V  AC  power  could  be  tocated 
centraily.  If  there  are  still  space  problems  then  some  or  all  of  the  2SV  DC  Power  1  switch 
elements  could  be  located  centrally. 

AVS  Implementation;  The  switching  elements  for  28V  DC  Power  1.  2dV  DC  Power  2,  and  115V 
AC  are  all  distributed,  being  located  in  the  store  station  equipment.  I’his  reduced  the  wiring 
required  in  the  AVS. 

5.1.5.2  Centralized  or  distributed  fault  isolation  elements  [10.1.5.1.2] 

ISSUE;  Where  should  fault  isolation  elements  be  located? 

RATIONALE;  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation;  The  fault  isolation  elements,  circuit  breakers,  were  located  in  the  Store 
Station  Equipment  but  positioned  after  the  switch  elements.  This  meant  that  circuit  breakers 
thai  had  'tripped'  were  not  detec.ed  until  the  outputs  were  activated. 

5.1. 5.3  Power  switching  elements  110.1.5.2.1] 

ISSUE;  What  type  of  power  switching  elements  should  be  used? 

RATIONALE:  MiL-STO-1760  states  that  the  voltage  level  at  the  ASI  shall  comply  with  the 
normal  and  abnormal  operation  characteristics  for  utilization  equipment  defined  in 
MIL-STD-704.  The  power  supply  provided  to  the  AIS  from  the  aircraft  power  systems  would 
have  to  be  well  within  the  limits  specified  by  MIL'STD-704  to  allow  for  voltage  drops  within 
the  AIS.  To  allow  a  reasonable  specification  for  (he  aircraft  power  system  the  vcilage  crops 
within  i.he  AIS  noed  to  be  mintmizod.  The  use  of  semiconductor  switching  elements  for  the  power 
lines  would  introduce  relatively  laige  voltage  drops  whereas  MIL-R  6106  or  similar  .'aiays 
introduce  very  small  voltage  drops. 

AVS  Implementation:  The  AVS  uses  MIL  R-6106  type  relays  ior  the  switching  of  ail  28V  DC 
power  1 , 28V  DC  Powar  2  and  1 15V  AC  power  lines.  The  voltages  on  these  lines  presented  at  aH 
the  ASI  met  the  requirements  of  MIL-STO-1760  under  all  valid  load  conditions  although  good 
quality  laboratory  supplies  were  used  to  supply  the  power 
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Test  and  Evaluate:  The  Mil.  3TD-1760  Test  Process,  Report  6  (Document  Number 
182/70/20),  concluded  lial  the  AVS  complied  with  all  the  requirements  of  MIL-STD-1760 
concerning  power  lines.  The  MIL-STD-1760  Evaluation  Process.  Report  5  (Document  Number 
182/70/26),  identified  that  the  voltage  drops  within  the  AVS  were  an  area  of  concern  and  every 
effort  should  be  made  to  minimize  the  voltage  drops  on  the  power  lines  for  an  on-aircraft  AEIS. 

5. 1.5.4  Isolaticn  Elements  (10.1.5.2.2) 

ISSUE:  What  type  of  fault  isolation  elements  should  be  used? 

RATIONALE:  MIL-STD-1760  gives  curves  defining  the  maximum  overcurrent  and  tHaximum 
load  current  against  duration  relationships.  These  curves  are  derived  from  figures  defined  in 
M!L-STD-1498  for  circuit  protection  devices.  Many  circuit  breakers  are  available  which 
conform  to  this  specification  nowever  the  characteristics  of  most  fuses  do  not  conform  to  these 
curves.  Therefore  great  care  must  be  taken,  if  fuses  are  to  be  used  as  the  Fault  isolation 
elements  in  the  power  lines,  to  ensure  that  the  characteristics  of  the  fuse  conform  with  those 
specified  in  MIL-STD-1760. 

5.1.5.5  Connectors  (10.1.5.3.1) 

ISSUE:  Guidance  for  the  connectors  for  Power  signals. 

RATIONALE:  As  discussed  in  paragraph  5.1. 5.3,  every  efforl  must  be  made  to  reduce  voltage 
drops  within  the  AIS.  Every  contact  in  the  power  lines  will  introduce  a  series  impedance  in  the 
line.  The  larger  the  contact  the  smaller  th’s  impedance  is.  Therefore  to  minimize  the  voltage 
drop  due  to  contact  impedance  the  largest  contact  practicable  should  be  used. 

AVS  Implementation:  All  the  contacts  used  for  Primary  power  signals  in  the  AVS  were  size  16 
contacts.  The  AVS  met  all  the  voltage  requirements  of  MIL-STD-1760  associated  with  the  power 
signals,  however,  the  AVS  was  powered  using  good  quality  laboratory  supplies 

Test  and  Evaluation:  The  MIL-STD-1760  Test  Process,  Report  6  (Document  Number 
182/70/20),  concluded  that  the  AVS  complied  with  all  the  requirements  of  MIL-STD  1760 
concerning  power  lines.  The  MIl-STD-1760  Evaluation  Process,  Report  5  (Document  Number 
182/70/26),  identified  that  the  voltage  dr^s  within  the  AVS  were  an  area  of  concern  and  every 
efforl  should  be  made  to  minimize  the  voltage  drops  on  the  power  lines  for  an  on-aircfaft  AEIS. 

5. 1.5.6  Cablmo  (10.1.5.3.2) 

ISSUE:  GuidarTce  for  cabling  for  Power  Signals. 

RATIONALE:  As  discussed  in  paragraph  5.t.5.3,  every  effort  must  bo  made  to  reduce  voltage 
drops  within  the  AIS.  The  cable  used  for  the  power  lines  will  introduce  a  series  impeoance.  Tlic 
larger  the  cabto  the  smaller  is  the  impedance  'nfroducod.  Therefore  to  minimize  the  voltage  drop 
due  to  the  cabling  then  the  largest  size  cable  that  is  practical  should  be  used. 

AVS  *mplemontation:  All  the  cabling  associated  with  the  primary  power  lines  was  implemented 
using  19/0.3  wire.  The  wirir^  between  the  Store  Station  Equipment  and  the  Auxiliary  Power 
Switch  (APS)  used  to  distribute  She  power  throughout  the  AVS,  used  four  19/0  i  cables 
connected  in  parallel.  The  AVS  met  all  the  requirements  of  MlL-STD-t750  associated  with  tne 
power  signals  however,  the  AVS  was  powered  using  Qood  quality  laboratory  supplies. 
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Test  and  Evaluation:  The  MlL-STD-1760  Test  Process,  Report  6  (Document  Number 
182/70/20),  concluded  that  the  AVS  complied  with  all  the  requirements  of  MIL-STO'1760 
concerning  power  lines.  The  MIL-STD-1760  Evaluation  Process,  Report  5  (Document  Number 
182/70/26),  identified  that  the  voltage  drops  within  the  AVS  were  an  area  of  concern  and  every 
effort  should  be  made  to  minimize  the  voltage  drops  on  the  power  lines  for  an  on-aircratt  AEIS. 

5.1. 5.7  Specific  2BV  DC  Power  1  guidance  (10.1.5.4.1) 

ISSUE:  What  specific  guidance  can  be  given  for  28V  DC  Power  1? 

RATIONALE:  MIL-STD-1760  States  that  The  aircraft  may  energize  28V  DC  Power  1  at  any  time 
under  the  assumption  that  all  store  functions  so  powered  are  either  not  safety  critical  or  that 
multiple  safety  interlocks  exist  within  the  store  such  that  store  safety  is  not  significantly 
degraded  by  activation  of  28V  DC  Power  1 

5.1 .5.8  Specific  2BV  DC  Power  2  guidance  (10.1.5..4.2) 

ISSUE:  What  specific  guidance  can  be  given  for  28V  DC  Power  2? 

RATIONALE:  MIL-STO-1760  states  that  The  aircraft  operation  shall  consider  that  some  stores 
may  utilize  28V  DC  Power  2  for  powering  safety  critical  functions  such  that  store  safety  may  be 
degraded  with  activation  of  this  power  interface.*  This  signal  should  therefore  be  treated  as  a 
safety  critical  power  supply  and  as  such,  as  many  of  the  recommendations  as  are  practical  for 
switching  of  safety  critical  signals  should  be  applied  to  this  line.  This  includes  directly 
interlocking  this  line  with  an  aircrew  selectable  safety  critical  switch  such  as  master  arm. 
MIL-STD-1760  also  states  that  ‘The  28V  DC  Power  2  Return  connection  shall  be  the  ground 
reference  for  release  consent.*  To  reduce  the  effects  that  may  occur  due  to  ditlerences  in  ground 
potential  across  the  aircraft  the  circuits  for  generating  Release  Consent  and  28V  DC  Power  2 
should  be  physically  close  together  and  derive  their  power  from  the  same  source. 

5.1. 5.9  Specific  115V  AC  guidance  (10.1.5.4.3) 

ISSUE:  What  specific  guidance  car.  be  given  for  1 15V  AC? 

RATIONALE:  MIL-STD-1760  slates  that:  ‘The  aircraft  may  energize  the  115V  AC  power 
interface  at  any  time  under  the  assumption  that  all  store  functions  so  powered  are  either  not 
safety  critica!  or  that  multiple  safety  interlocks  exist  within  the  store  such  that  store  safety  is 
not  significantly  degraded  by  activation  of  115V/200V  AC  power.”  Figure  5.4  shows  three 
options  for  implementing  the  switching  of  115V  AC  power.  Option  A  uses  a  single  three  pole 
relay  to  switch  all  phases  simultaneously.  This  approach  uses  a  single  relay  but  if  this  interface 
is  used  to  power  existing  stores  that  only  require  a  single  phase,  such  as  AIM-9L,  then  the 
remaining  two  phases  may  be  active  but  left  unconnected.  Option  B  shows  separate  relays  being 
used  to  switch  each  phase  independently.  This  could  cause  problems  to  stores  which  r^uire  all 
three  phases  to  be  applied  simultaneously.  As  the  switching  times  of  the  three  relays  will  vary 
there  could  be  a  delay  of  up  to  10  ms  between  one  phase  becoming  active  and  another  phase 
becoming  active.  Option  C  overcomes  both  of  the  above  problems  but  at  the  expense  of  adding 
extra  relays.  This  will  increase  the  size  and  the  cost  of  the  circuitry  required  to  implement  the 
switching  of  115V  AC  power. 
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5.1.6  Auxiliary  signal  set  issues 


5.1.6.1  28  Volts  Power  [10.1.6.1.11 

ISSUE:  What  guidance  can  be  given  for  Auxiliary  28V  DC? 

RATIONALE:  The  same  rationale  applies  to  Auxiliary  28V  DC  power  as  given  for  28V  DC  Power  2 
in  paragraph  5.1 .5.  The  physical  size  of  the  switching  elements  required  to  switch  the  30  Amps 
for  Auxiliary  28V  DC  is  far  larger  than  those  required  for  28V  DC  power  2  and  so  the  problems 
with  limited  space  in  the  store  station  equipment  becomes  far  more  significant. 

AVS  Implementation:  The  AVS  implements  the  Auxiliary  power  switching  in  a  central  unit,  the 
Auxiliary  Power  Switch  (APS).  This  significantly  reduced  the  amount  of  circuitry  required  in 
the  store  station  equipments  and  hence  significantly  reduced  their  size.  Positioning  all  the 
auxiliary  power  switches  together  made  it  far  easier  to  isolate  these  switches  so  that 
interference  caused  by  switchirig  the  high  currents  did  not  interfere  with  other  circuitry. 

5.1 .6.2  115  Volts  [10.1.6.1.21 

ISSUE:  What  guidance  can  be  given  for  Auxiliary  115V  AC? 

RATIONALE:  The  same  rationale  applies  to  auxiliary  115V  AC  power  as  given  for  pri '  '  115V 

AC  in  paragraph  5.1.5. 

AVS  Implementation:  See  paragraph  5. 1.6.1 

5.1.6.3  AiMiaft  JniflflQck  .MflniioLina  (10.1.6.21 

ISSUE:  What  guidance  can  be  given  for  Auxiliary  interlock  monitoring? 

RATIONALE:  The  rationale  for  this  issue  is  the  same  as  given  for  the  primary  interlock  signal  in 
paragraphs  5.1. 4.4  and  5. 1.4.5. 

5.1. 6.4  Auxiliary  Structure  Ground  [10.1.6.3] 

ISSUE:  What  guidance  can  be  given  for  auxiliary  structure  ground? 

RATIONALE:  The  rationale  for  this  issue  is  the  same  as  given  for  the  primary  structure  ground 
line  in  paragraph  5.1. 4.8. 

5.1.7  Connector  Issues 

5.1 .7.1  High  Bandwidth  contacts  [10.1.7.1.1] 

ISSUE:  What  contacts  should  be  used  for  High  Bandwidth  signals? 

RATIONALE:  The  spedficaiions  for  contacts  in  slash  sheets  /28  and  /75  to  MIL-C-39029  are 
too  generalized  for  use  with  Type  6  signals  as  specified  ^n  MIL-STD-1760.  Contacts  conforming 
to  these  slash  sheets  cannot  be  guaranteed  to  meet  the  VSWR  rec^irenients  ftM’  the  type  B  signals. 
New  slash  sheets  have  been  released  which  specify  contacts  specific^  intended  to  be  used  for 
the  Type  B  signals  defined  in  MIL  STD-1760  such  that  contacts  conforming  to  tftese  new  slash 
sheets  (/102  and  /1 03)  are  guaranteed  to  meet  the  VSWR  requirements  of  MIL-STD-1760. 
These  cont^s  should  now  be  used  for  the  Type  B  signals  carried  on  High  BwKfwidth  i .  In 
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addition,  as  contacts  conforming  to  slash  sheets  /1 02  and  /1 03  have  a  characteristic  impedance 
of  50  ohm,  then  these  contacts  would  also  be  suitable  for  High  Bandwidth  2  signals  which  are 
specified  in  MIL-STD-1760  as  also  having  a  characteristic  impedance  of  50  ohms.  High 
Bandwidth  3  and  4  are  specified  as  having  a  characteristic  impedance  of  75  ohms,  so  contacts 
conforming  to  /28  and  /75  would  be  more  suitable  for  these  signals. 

5.1.7.2  Other  Guidance  (10.1.7.1.2] 

ISSUE;  What  other  Guidance  can  be  given  for  the  primary  connector? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

5.1.8  Reserved  Provistons  Issues 

5.1.8.1  Fiber  Ootic  connector  contacts  (10.1.8.1.1) 

ISSUE:  What  connector  contact  provision  should  be  made  for  Fiber  Optic  signals. 

RATIONALE:  The  contacts  for  Fiber  Optic  signals  have  not  been  specified  therefore  cannot  be 
fitted. 

5.1. 8.2  Hardware  Provision  tor  Fiber  Optic  (10.1.8.1.2) 

ISSUE:  What  hardware  provisions  should  be  made  for  Fiber  Optic  signals? 

RATIONALE:  Specifications  for  Fiber  Optic  cables  or  terminals  to  be  used  for  MIL-STD-1760  do 
not  exist  therefore  no  provisions  can  be  made. 

5.t.8.3  Hardware  Provision  for  27QV  DC  (10.1.8.2.1) 

ISSUE:  What  hardware  provisions  should  be  made  for  the  270V  DC  signals? 

RATIONALE:  It  is  good  practice  to  provide  expansion  capabilities  in  ali  units. 

5.1. 8.4  Connector  Provisions  tor  27QV  DC  (10.1.8.2.2) 

ISSUE:  What  connector  provisions  should  be  made  lor  the  270V  DC  signals? 

RATIONALE:  The  size  16  contacts  are  already  specified  therefore  these  can  be  fitted  where 
appropriate. 

5.1. 8.5  Cabling  Provision  tor  27QV  DC  (10.1.8.2.3) 

ISSUE;  What  cabling  provisions  should  be  made  for  the  270V  DC  signals? 

RATIONALE;  It  is  good  practice  to  provide  spare  wires  in  cable  runs,  where  appropriate,  to 
minimize  the  effects  of  modifications. 


5.2  Detailed  Guidance  on  Specific  Issues 
5.2.1  Safety  Critical  Switching 
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5.2.1. 1  Number  of  Switch  elements  [10.2.1.1] 

ISSUE:  How  many  switch  elements  should  be  provided  in  safety  critical  signal  paths? 

RATIONALE:  To  meet  the  usual  safety  critical  requirement  that  no  single  fault  shall  cause  the 
inadvertent  activation  of  a  safety  critical  outTAit.  then  at  least  two  switch  elements  need  to  be 
provided  in  the  signal  path.  To  be  able  to  fully  test  the  safety  critical  output  circuits  then  each  of 
the  switch  elements  should  be  activated  during  a  built  in  test  sequence.  To  ensure  that  the  no 
single  fault  requirement  stated  above  is  still  met  during  this  test  sequence,  a  third  switch 
element  is  required  to  ensure  that  the  circuit  can  be  safely  exercised  even  under  fault  conditions. 
Adding  more  switch  elements  would  not  greatly  improve  the  overall  safety  of  the  circuit  and 
would  significantly  affect  the  reliability  of  the  circuit. 

5.2.1. 2  Position  of  Switch  elements  (10.2.1.2) 

ISSUE:  Where  should  the  safety  critical  switch  elements  be  located  ? 

RATIONALE:  The  rationale  for  this  issue  is  the  same  as  given  for  the  release  consent  signal  in 
paragraph  5. 1.4.1. 

5.2.1. 3  Iypfi,Qt  switch  elements  (10.2.1.3) 

ISSUE:  What  type  of  switch  elements  should  be  used  tor  safety  critical  signals? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  Most  of  the  safety  critical  outputs  from  the  AVS  have  both  a  mechanical 
switch  and  a  semiconductor  switch  in  the  signal  path.  This  combination  was  found  to  work  well 
within  the  AVS  producing  switch  response  times  in  the  order  of  0.3  ms  for  semiconductor 
switches  compared  with  1 0  ms  for  mechanical  switches  enabling  very  accurate  control  of  pulse 
widths  on  these  signal  lines. 

Test  and  Evaluation:  The  AVS  Evaluation  Process,  Report  8,  Issue  2,  Document  Number 
182/70/35,  measures  the  response  time  of  the  safety  critical  outputs  from  the  elements  on  the 
armaments  bus.  This  shows  response  times  in  the  order  of  0.3  ms  for  the  EJECT  A  and  FIRE  A 
outputs  which  have  semiconductor  switching  elements,  and  response  times  of  10.9  ms  for 
Release  consent  which  is  controlled  by  mechanical  switches. 

5.2.2  Safety  Critical  data  transfer  (10.2.2) 

ISSUE:  Guidance  for  safety  critical  data  transfer  on  MIL-STD-1553  bus. 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  The  AVS  implements  a  system  similar  to  that  given  as  an  exan^  in 
Appendix  A.  The  selection  of  a  safety  critical  switch  (such  as  MAS,  Trigger,  etc.),  generates  an 
interrupt  lo  the  SMS  processor.  This  processor  then  generates  the  relevant  critical  command 
words  within  the  appropriate  messages  and  passes  these  to  the  Bus  Controller  processor  for 
transmission  on  the  MIL-STD-1553  Armaments  Bus.  The  Bus  Controller  processor  identifies 
that  a  critical  command  word  is  to  be  transmitted  and  that  an  associated  critk^l  authority  word 
is  required.  This  processor  then  generates  the  critical  authority  word  by  obtaining  the  relevant 
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information  from  an  authority  code  table.  However,  access  to  this  code  table  is  limited  by 
separate  discrete  monitors  of  the  critical  switch  inputs  such  that  access  can  only  be  obtained  to 
those  codes  relevant  to  the  critical  state  presently  demanded  by  the  critical  switches.  The  Bus 
Controller  processor  then  inserts  the  critical  authority  word  in  the  appropriate  message  and 
transmits  the  completed  message  on  the  MIL-STO-t5S3  armaments  tfos. 

5.2.3  Use  of  Standard  Modules 

5.2.3.1  Process  Control  Equipment  {PCE)  (102.3.1] 

ISSUE:  Can  standard  modules  be  used  in  the  PCE? 

RATIONALE:  The  use  Of  common  modules  would  reduce  development  time  and  cost,  probably 
reduce  prorfoction  costs  and  will  reduce  the  spares  slock  required  to  support  the  equipments. 

5.2.32  Store  Station  Equipments  fSSEt 

ISSUE:  Can  startdard  modules  be  used  to  SSE? 

RATIONALE:  Tpo  use  of  common  modules  is  desirable  to  reduce  development  time  and  cost,  to 
probably  reduce  production  costs  and  to  reduce  the  spares  stock  required  to  support  the 
equipments. 

5.2.4  Built  in  tesL  circuitry  (10.2.4) 

ISSUE:  What  guidance  can  be  given  for  BIT  circuitry  in  the  AIS? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

5.2.5  ConnSClOiS  (10.2.5) 

ISSUE:  What  guidance  can  be  given  tor  connectors  to  be  used  within  the  AIS. 

RATIONALE:  The  rationale  was  provided  in  paragraphs  10.2.5  and  9.3.1 .3  of  the  Appendix  A 
guidance  artd  no  further  rationale  is  necessary. 

5.2.6  Connector  Din  altocations  (10.2.6) 

ISSUE:  Guidance  for  signal  allocation  in  non-ASI  connectors. 

RATIONALE:  Using  guard  contacts  at  ground  potential  will  ensure  that  any  adjacent  pin  shorts  to 
the  safety  critical  signal  being  protected  will  be  detected,  as  this  short  will  blow  a  fuse  or  trip  & 
circuit  breaker  as  soon  as  the  safety  critical  signal  is  activated.  However,  such  a  short  could 
cause  an  ‘earth  loop*  which  in  some  situations  could  itself  be  a  safety  hazard.  If  this  is  the  case 
then  open  circuit  guard  pins  could  be  used  but  then  an  adjacent  pin  short  vmuld  not  be  detected. 
High  current  or  high  voltage  signals  can  generate  a  lot  of  electromagnetic  interference  when 
voltages  or  currents  on  these  lines  are  changed.  To  prevent  this  from  disrupting  other  signals 
then  these  high  current  and  high  voltages  signals  should  be  separated  from  other  types  of  signal. 
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ISSUE:  Guidance  on  physical  design  of  equipment. 

RATIONALE:  Circuitry  associated  with  high  currents  or  high  voltages  can  generate  considerable 
electromagnetic  interference.  To  prevent  this  disrupting  other  circuits  these  high  current  or 
high  voltage  circuits  should  be  kef^  physically  separate  from  other  circuitry. 

5.2.8  Electfomaanetic  Considerations  (EMC.  EMP.  TEMPEST!  (10.2.8) 

ISSUE:  Eftects  on  AIS  design  due  to  EMC,  EMP  and  TEMPEST. 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidarx^  and  no  further  rationale  is 
necessary. 
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6.  RATION.ALE  FOR  APPENDIX  A  SECTION  11 


Paragraphs  6.1.1  through  6.2.22  of  this  section  provide  rationale  derived  from  the  AVS  and 
other  sources  to  support  the  guidance  given  in  paragraphs  11.1.1  through  11.2.9  of  Appendix  A. 
Issue  statements  arid  subjects  have  been  summarized  in  some  paragraphs.  Where  rationale  was 
supplied  in  the  guidance  text,  and  further  provision  considered  superfluous,  then  extra  rationale 
is  not  provided. 

6.1  MIL-STD-1760  LDP  Implementation  This  section  provides,  when  applicable,  additional 
rationale  and  details  of  the  AVS  implementation  for  the  issues  raised  in  section  11.1  of  Appendix 
A 


6.1.1 


(11.1.11 


ISSUE;  Generic  software  versus  store  specific  software. 

RATIONALE;  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation;  The  LDD  requirements  allowed  the  developments  of  truly  generic  software 
packages  capable  of  selecting,  controlling  and  realizing  mission  stores  compliant  with  the 
standard.  The  main  AVS  PCE  SMS  processor  packages  responsible  for  the  LDD  generic  software 


were; 

a 

PCE  SMS  Level  5  package; 

Ml 760  STORE  CONTROL 

b. 

PCE  SMS  Level  4  package; 

STORE  .DESCRIPTIONS 

c. 

PCE  SMS  Level  4  package; 

STATE  (Safety  critical) 

d 

PCE  RTS  Level  package; 

DATA  ENTITIES 

e. 

PCE  SMS  Level  3  package; 

MESSAGE.FAJLURE 

f. 

PCE  BC  module; 

SRPROC  (Service  Request  Extraction) 

g- 

PCE  BC  module; 

SFPROC  (Bitlog  processing) 

Multiple  mission  types  (AGM,  SRAAM,  and  BOMB)  were  controlled  using  these  generic  modules. 

6.1.2  Store.Powef-UD  Timing  (11.1.2.1) 

ISSUE;  When  should  mission  stores  be  first  powered  up? 

R.ATIONALE;  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation;  The  AVS  always  powers  mission  stores  at  PCE  power  application  to  identify 
the  mission  store  type  such  that  the  inventory  could  be  established.  Power  was  then  left  on  from 
this  time  until  the  store  was  released.  Keeping  power  on  throughout  the  mission  would  rwi  be 
adopted  for  a  flight  implementation. 

6.1.3  Reduction  of  Power  Up  Time  (11.1.2.2) 

ISSUE;  Software  design  to  minimize  system  configuration  time  from  power  up. 

RATIONALE;  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 
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A  vs  Implementation;  The  AVS  PCE  did  not  implement  a  concurrent  type  of  scheme.  Itsequencod 
around  each  pylon  and  therefore  each  mission  store.  During  inventory  upload  this  ir^ciuded 
initiating  Interruptive  BIT  to  each  pylon's  controlling  SSE.  Consequently  the  time  taken  to 
establish  inventory  at  power  up  was  very  long  indeed  (up  to  15  seconds).  The  main  reason  for 
this  implementation  was  to  allow  the  automatic  detection  of  existing  stores.  The  AVS  solution  was 
not  optimized  and  is  not  being  offered  for  guidance.  Figure  1 1 .3  of  Appendix  A  is  not  relevant  to 
the  AVS. 

6.1.4  Error  Checking  111.1.2.3) 

ISSUE:  What  error  checking  should  be  made  by  an  AIS  during  mission  store  power  up? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  The  AVS  did  not  indude  any  specific  power  up  chockirtg  software  but  simply 
used  the  normal  error  management  software.  Because  the  AVS  just  wailed  500  ms  after  applying 
mission  store  power  it  was  not  necessary  to  impose  the  checks  provided  in  figure  1 1 .4  of 
Appendix  A.  The  AVS  solution  was  tailored  to  AVS  requirements  and  would  not  be  suitable  as  a 
generic  solution. 

6.1.5  Subaddress  Allocation  (11.1.3) 

ISSUE;  Allocation  of  subaddress  to  stores  and  remote  interface  units. 

RATIONALE;  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  hiither  rationale  is 
necessary. 

AVS  Implementation:  The  AVS  dkJ  not  apply  additional  subaddress  checking.  It  did,  however, 
ensure  that  safety  critical  subaddresses  were  only  generated  at  one  point  within  the  application 
code. 

6.1.6  Checksum  Generation  Point  (11.1.4.1) 

ISSUE:  Should  the  checksum  generation  be  implemented  in  software. 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary, 

AVS  Implementation:  The  AVS  PCE  implementation  is  to  generate  checksums  in  software.  It  was 
performed  by  the  Bus  Controller  (BC)  firmware.  The  reason  it  was  located  here  was  that 
messages  requiring  system  time  were  processed  by  the  BC.  It  was  therefore  necessary  to 
calculate  the  checksum  after  the  system  time  was  latched  in.  The  AVS  solution  worked  well  and 
time  available  allowed  the  necessary  Motorola  68000  microprocessor  instructions  required  to 
implement  the  checksum. 

6.1.7  LDP  Checksum  Computation  (11.1.4.2) 

ISSUE;  What  are  the  effects  of  computing  the  LDD  checksum? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 


374 


AVS  Implementation;  The  checksum  is  implemented  in  the  BC  firmware  in  the  manner  discussed 
in  the  guidance.  This  proved  to  be  a  very  successful  implementation. 

6.1.8  Use  of  Store  Description  Protocol  [11.1.5.1] 

ISSUE;  What  effects  upon  so^ware  design  are  imposed  by  the  store  description  protocol? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  fuilher  rationale  is 
necessary. 

AVS  Implementation:  The  AVS  implements  the  full  protocol  specified  in  the  LDD  entirely  within 
the  PCE  SMS  processor.  Within  the  software  titled  PCE  SMS  processor  Level  4  package; 
STORE_DESCRIPTIONS.  a  flexible  data  structure  of  the  type  recommended  in  figure  11.6  of 
Appendix  A  is  used.  The  structure  met  the  goals  of  reducing  the  si^e  to  match  the  inventory 
requirements  but  an  overhead  is  incurred. 

6.1.9  Inventory  Data  Base  Structure  [11.1.5.2] 

ISSUE:  How  should  the  AIS  inventory  data  base  be  structured  to  best  use  the  store  description 
data? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  Within  the  PCE  Inventory  data  structure,  provision  is  made  for  the  store 
identity  and  the  ASCII  string.  The  st  ing  is  used  by  the  upload  package  Store_Descriptions  to 
determine  what  type  of  emulated  MIL-STD-1760  store  is  being  used.  The  inventory  is  then 
configured  from  this  information  and  passed  to  the  display  system. 

6.1.10  Usage  of  Standard  Software  [11.1.6.1] 

ISSUE:  Can  standard  safety  critical  software  for  control  of  mission  stores  be  used? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation;  The  AVS  PCE  software  solution  is  to  contain  all  safety  critical  state  control 
in  one  Ada  package,  PCE  SMS  Level  4  package  STATE.  This  package  combined  with  the  data 
package  indicating  current  state  (PCE  SMS  Level  4  package  CRITICAL-CONTROL-MESSAGE) 
generates  all  critical  control  words  and  the  safety  critical  subaddress  to  change  the  state  to  a  new 
requested  store.  The  package  also  performs  the  safety  critical  monitor,  checking  both  demanded 
and  acquired  monitor  fields.  The  AVS  PCE  software  solution  also  included  the  generation  of  the 
safety  critical  messages  for  SSEs  in  the  same  Ada  package.  This  solution  worked  very  well  and 
the  software  required  to  effect  safety  critical  stale  changes  are  contained  in  two  Ada  packages. 

6.1.11  Software  Structure  [11.1.6.2] 

ISSUE:  What  software  structure  should  be  used  for  safety  critical  processing? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 
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AVS  Implementation:  As  described  in  the  AVS  implementation  for  [11.1.6.1]  all  safety  critical 
software  was  separated  from  remaining  mission  critical  software  via  an  Ada  package  in  the  SMS 
processor.  The  generation  of  the  authority  codes  was  performed  by  the  PCE  BC  firmware 
whenever  it  detected  a  receive  subaddress  1 1  message  and  was  therefore  separated  from  the 
critical  control  word  building  software.  The  AVS  solution  did  not  include  a  separate  safety 
critical  acyclic  queue  in  the  BC.  Safety  criticai  message  shared  an  acyclic  queue  with  Mission 
Critical  messages.  This  implementation  was  successful,  but  would  result  in  more  complicated 
software  validation  activities  for  safety  critical  systems. 

6.1.12  Usage  of  Monitor  Message  [11.1.6.3] 

ISSUE:  How  should  the  AIS  use  safety  critL-i  mcmtor  message? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Impiementation:  Within  the  PCE  SMS  processor  Level  4  Ada  package  STATE,  a  monitor 
message  was  always  sequenced  after  a  control  message.  Checks  are  made  after  20  ms  for  the 
acknowledgment  of  the  demand  by  checking  the  demand  field.  One  re-check  is  scheduled  if  this 
first  check  fails.  Then  every  20  ms  for  up  to  500  ms  a  check  is  made  on  the  acquired  field.  If 
after  500  ms  the  requested  state  is  not  attained  by  the  mission  store,  then  the  request  is 
indicated  as  failed.  This  mechanism  works  very  well.  What  was  not  implemented  in  the  PCE  was 
the  re-sequencing  through  the  safety  critical  states  upon  state  change  error.  The  PCE  response 
was  to  ’hang"  the  mission  store.  This  approach  is  not  sufficient  for  a  flight  system,  whereas  the 
approach  offered  in  the  guidance  is. 

6.1.13  Software  Design  for  State  Control  [11.1.6.4] 

ISSUE:  What  software  design  is  required  to  support  safety  aitical  state  control? 

RATIONALE;  The  rationale  was  provioed  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  The  implementation  suggested  in  the  Appendix  A  guidance  is  based  upon  the 
AVS  implementation  which  used  a  generic  store  controller  built  around  the  safety  critical  states 
to  control  mission  stores.  The  AVS  did  not  implement  a  true  finite  state  implementation,  but  if  it 
had,  then  the  integrity  of  software  would  have  been  increased. 

6.1.14  Status  Word  Bit  Effects  [11.1.7.1] 

ISSUE:  What  is  the  effect  on  software  design  of  each  status  word  bit  either  having  a  specified  use 
or  not  being  allowed  to  be  used? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation;  Within  the  PCE  BC  firmware,  a  common  status  word  handling  routine  was 
used.  It  was  responsible  for  decoding  the  bit(s)  and.  If  needed,  assigning  priorities  to  them. 

Each  bit  set  had  an  associated  handling  module  and  these  were  applicable  to  all  RT  types 
(including  non  mission  store  units,  such  as  SSEs  and  SNEs)  employing  the  same  LCD  protocol. 
With  this  scheme  the  software  was  reduced  and  it  freed  the  main  SMS  processor  from  error  bit 
handling. 
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6.1.15  Mode  Code  Effects  (11.1.7.2) 

ISSUE:  What  are  the  effects  on  software  design  of  restricting  the  number  and  use  of  mode  codes? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  Only  a  certain  number  of  Mode  Codes  are  used  in  the  AVS  Implementation: 

?.  Transmit  Vector  Word 
o.  Synchronize  with  Data 
c.  Reset  Remote  T  erminal 

It  was  not  possible  to  develop  a  full  error  management  procedure  embodying  all  available  mode 
cods’:.  The  used  set  were  considered  to  be  sufficient. 

6.1. It’  Vector  Word  Erfects  (11.1.8.1) 

ISSUE:  What  are  the  effects  upon  AIS  software  design  caused  by  the  extraction  of  vector  words? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  In  response  to  service  request,  the  PCE  BC  firmware  initiates  the  specified 
protocol  to  extract  all  available  data  words.  It  then  presents  these  data  words  to  the  SMS 
processor  for  decoding  and  action.  This  scheme  worked  well  as  it  freed  the  SMS  processor  from 
the  vector  word  extraction  protocol.  The  SMS  processor  is  the  best  place  to  decode  the  vector 
words  because  this  type  of  intelligence  should  not  be  built  into  BC  firmware. 

6.1.17  Checksum  Failure  Recovery  (11.1.8.2) 

ISSUE:  What  are  the  effects  upon  AIS  software  design  in  holding  the  last  two  transmit  messages 
for  a  mission  store  to  ensure  recovery  from  a  checksum  failure? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  The  AVS  implements  the  scheme  offered  in  the  guidance.  Holding  Buffers 
are  available  for  each  RT  for  the  last  receive  (RX)  message.  This  scheme  complicated  message 
transmission  software  with  a  resultant  effect  on  intermessage  gaps.  As  a  scheme  it  worked  well 
but  by  its  very  nature  It  was  an  'untidy'  software  solution. 

6.1.18  Error  Management  (11.1.8.3) 

ISSUE:  Effects  of  a  suitable  error  management  procedure. 

RATIONALE:  The  rationale  was  provided  In  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  The  AVS  dkj  not  action  all  of  the  flags  embedded  within  the  extracted  word, 
it  only  took  action  on  checksum  failures  (by  Instructing  the  PCE  BC  firmware  to  retransmit  the 
last  2  receive  (RX)  messages)  and  the  code  indicating  no  3  phase  power.  In  all  other  cases  the 
mission  store  was  shut  down.  This  solution  would  be  unacceptable  in  an  aircraft  implementation. 
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It  had  to  be  this  way  in  the  AVS  to  tailor  the  software  task  to  the  available  funds.  In  dealing  with 
a  standard  vector  word,  care  has  to  be  taken  in  the  field  processing  software. 

6.1.19  Asynchronous  Message  Scheduling  {11.1.8.4) 

ISSUE:  How  sl  .ould  the  AIS  software  implement  scheduling  of  asynchronous  message  transactions 
requested  from  a  mission  store? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  The  AVS  PCE  did  not  implement  the  scheduling  of  asynchronous  message 
transactions.  This  was  related  to  the  complexity  of  the  task  and  the  available  funding  for  the 
software  development. 

6.1.20  Subsystem  Flag  Response  {11.1.8.51 

ISSUE:  How  should  the  AIS  software  respond  to  the  Subsystem  Flag  (bit  time  17)7 

RATIONALE;  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation;  The  AVS,  in  response  to  subsystem  flag,  would  first  schedule  a  Reset 
Terminal  Mode  Code  such  that  the  flag  can  be  reche<^ed.  Upon  valid  subsystem  flag  the  PCE  BC 
firmware  would  determine,  from  dual  ported  RAM  set  up  during  store  descriptions  upload, 
whether  the  RT  implemented  a  BIT  LOG  word,  if  it  did,  then  it  would  oe  extracted  by  scheduling  a 
transmit  (TX)  message  transaction  for  the  associated  subaddress.  The  BIT  LOG  word  would  then 
be  presented  to  the  SMS  processor  for  decoding.  Decoding  in  the  AVS  solution  is  to  simply  store 
the  data  word  for  future  interrogation. 

6.1.21  Built  in  Test  Loo  (BIT  LOG1  Extraction  {11.1.8.6] 

ISSUE;  How  should  the  AIS  software  implement  BIT  LOG  word  extraction? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation;  The  BIT  LOG  word  position  is  saved  on  dual  ported  BC  RAM  during  store 
description  processing.  If  implemented  by  the  mission  store,  it  is  the  PCE  BC  firmware's 
responsibility  to  extract  the  BIT  LOG  word  from  the  mission  store.  The  decision  to  r.^ake  the  BC 
firmware  responsible  for  the  BIT  LOG  word  extraction  was  based  on  removal  of  this  function 
from  the  SMS  processor  because  it  was  not  easily  dealt  with  in  the  fully  synchronous  nature  of 
the  SMS  BC  acyclic  communication.  Such  a  synchronous  scheme  would  not  be  adopted  for  a  flight 
solution  and  the  SMS  processor  could  have  the  responsibility  of  BIT  LOG  word  extraction. 
However  the  BC  firmware  should  still  have  the  responsibility  of  validating  the  subsystem  flag  by 
automatically  scheduling  a  Reset  Terminal  nxide  code. 

6.1.22  Busy  Bit  Management  {11.1.8.7) 

ISSUE:  How  should  the  AIS  implement  busy  bit  management? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 
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AVS  implementation:  All  busy  bit  management  Is  handled  by  the  PCE  BC  firmware.  The  design  of 
this  firmware  Is  such  that  it  can  handle  multiple  RTs  being  busy  simultaneously.  The  BC 
firmware  will  schedule  an  'initiate  self  test'  mode  code  to  the  busy  RT.  This  mode  code  has  the 
advantage  that  it  always  returns  the  current  status  word  allowing  the  clearing  of  the  busy  bit  to 
be  determined  by  the  BC.  The  BC  will  keep  scheduling  (interleaved  with  other  acyclics,  cycilcs 
and  even  other  RT  busy  clearing  activity)  this  mode  code  until  it  is  cleared  or  4000  attempts 
have  been  made.  If  the  RT  is  excessively  busy  then  it  is  indicated  as  a  failed  RT  to  the  SMS 
processor.  This  implementation  takes  no  account  of  LDD  busy  times.  However  it  is  successful 
and  as  long  as  the  mission  store  is  compliant  with  the  busy  times,  then  throughput  is  maximized 
without  the  need  for  timers  and  special  busy  software. 

6.1.23  Data  Bus  Error  Handling  (11.1.8.8) 

ISSUE:  How  should  the  AIS  manage  data  bus  errors  in  general? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  The  PCE  BC  firmware  is  responsible  for  all  data  bus  errors  (protocol  or 
status  word  errors).  The  design  in  the  main  follows  the  guidance  offered.  If  did  result  in  a 
relatively  complex  scheme  but  provided  real  benefits  in: 

a  The  SMS  processor  was  relieved  of  this  responsibility. 

b.  Only  hard  errors  on  both  buses  resulted  in  mission  stores  being  shut  down. 

6.1.24  Retry  .  Strategy.  (11. 1.8.9] 

ISSUE:  What  is  a  general  error  retry  scheme  for  data  bus  failures  using  primary  and  secondary 
buses. 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  See  6.1 .22.  The  flowchart  offered  in  the  guidance  is  very  similar  to  the  BC 
firmware  implementation.  This  scheme  works  very  well  within  the  AVS. 

6.1.25  Checksum  Failure  Recovery  (11.1.8.10) 

ISSUE:  How  should  the  AIS  implement  recovering  from  checksum  failure  under  Notice  2/3. 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  Notice  2/3  requirements  are  not  implemented. 

6.1.26  S(zs-ancLEfl.£f.flf.maDCQJmpro.v.Qmflnts  (11.1.9.1) 

ISSUE:  How  can  software  size  and  performance  requirements  be  improved  if  all  measurement 
data  is  with  respect  to  standard  coordinate  systems? 

RATIONALE:  The  rationale  was  provided  In  the  Appendix  A  guidance  and  no  further  rationale  Is 
necessary. 
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AVS  Implementation:  Within  the  AVS,  the  avionics  data  bus  simulation  of  other  avionics 
subsystem  (such  as  INS,  FCC,  etc.)  data  entities  were  to  LDD  scaling.  This  meant  that  no 
conversion  software  was  required  by  the  Avionics  processor  in  the  PCE.  This  may  not  be  typical 
of  a  flight  system  where  avionic  data  may  either  not  be  available  as  a  single  data  entity 
(converted  from  other  entities),  or  the  scalings  of  such  data  may  be  inconsistent  with  LDD 
scalings. 

6.1.27  Benefits  of  Common  Data  Entities  (11.1.10.1] 

ISSUE:  How  should  the  AIS  software  be  structured  to  maximize  the  benefits  of  comnx>n  data 
entity  definitions? 

RATIONALE:  A  real  reduction  in  processing  power  requirements  within  the  AIS  is  achieved  by  the 
fact  that  no  data  conversion  is  required  for  different  store  types.  Data  conversion  should  be 
performed  as  fast  as  possible  to  reduce  any  data  latency  effects. 

AVS  Implementation:  All  data  relevant  to  the  current  selected  package  is  held  in  a  shared  memory 
-  entity  data  base.  It  is  placed  into  this  data  base  as  soon  as  the  data  has  been  processed  (by  the 
avionics  processor  for  incoming  data  and  the  SMS  processor  for  store  sourced  data). 

6.1.28  Discrete  Control  Management  {11.1.10.2) 

ISSUE:  How  should  the  AIS  manage  the  Discrete  Control  Word  1? 

RATIONALE;  The  rationale  was  provided  in  the  Apperrdix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  The  discrete  control  word  is  used  to  control  all  modes  for  the  AVS  1760 
missile  evaluation;  the  implementation  mapping  is  as  provided  In  Table  6.1. 

TABLE  6.1  Store  Targeting  Modes  via  discrete  control  word  1 


Targeting  Mode 

Boresight 

Autolock 

Widen 

Narrow 

Deselect  Taraetina 

1 

0 

X 

X 

Caged 

1 

1 

X 

X 

Boresight 

1 

1 

0 

1 

X 

X 

Scan 

nifmi 

1 

1 

X 

X 

Lock 

1 

1 

1 

X 

X 

Unlock 

0 

1 

1 

0 

X 

X 

Magnify 

X 

X 

X 

X 

0 

1 

Unmaonify 

X 

X 

X 

X 

1 

0 

6.1.29  System  Time  Management  (11.1.10.3) 

ISSUE:  How  should  the  AIS  software  manage  system  time  to  ensuie  synchronsm  on  the  stores 
data  bus? 


RATIONALE:  The  rationale  was  provided  in  the  Appeixlix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  A!i  system  time  required  to  be  transmitted  in  messages  to  mission  stores 
has  the  system  time  latched  in  by  the  BC  firmware  after  the  message  transaction  request  has 
been  de-queued.  This  ensures  the  most  recent  system  time  is  sent.  Additionally,  at  the  moment 
that  any  synchronize  with  data  mode  codes  are  de-queued  and  sent  then  the  system  time  is  saved. 
This  time  can  then  be  used  for  accuracy  checking.  The  AVS  scheme  worked  very  well. 

6.1.30  Usage  of  Store  IBIT  Time  (11.1.10.4) 

ISSUE:  How  should  the  AIS  software  use  the  uploaded  Mission  Store  Interruptive  BIT  duration. 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  The  AVS  PCE  software  design  solution  does  r)ot  use  uploaded  IBIT  duration 
times  during  mission  store  IBIT  processing.  Us  IBIT  sctieduling  is  very  simplistic,  sequencing 
IBITS  for  each  pylon  ar>d  waitirig  500  ms  after  the  initiation  of  IBIT  of  a  mission  store. 

6.1.31  Fuzing  Control  (11.1.10.5) 

ISSUE:  Control  of  fuzing  using  the  Fuzing  Control  word. 

RATIONALE:  The  rationale  was  provided  in  t.he  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  The  AVS  only  uses  the  fuze  setting  “Function  at  impact."  A  representation 
of  the  complete  fuzing  word  is  available  in  the  PCE  SMS  level  4  package 
CRITICAL_CONTROL_MESSAGE.  A  dedicated  procedure  is  used  to  fuze  the  mission  store  (a  PCE 
SMS  level  4  package  procedure  named  M1760_MESSAGES.  FUZE_STORE).  This  is  called 
whenever  the  associated  mission  store  is  taken  to  the  execute  arming  state. 

6.1.32  Validity  Word  Management  (11.1.10.6) 

ISSUE:  How  should  the  AIS  software  manage  Validity  Words? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  Refer  to  (11.1.10.6)  and  the  following: 

a  Validity  words  were  used  as  change  markers.  This  only  worked  because  the  mission 
store  emulation  software  made  the  same  assumption. 

b.  The  safety  critical  control  word  in  the  safety  critical  subaddress  was  sometimes 
marked  as  invalid  even  if  it  was  valid  (see  a).  This  solutiofi  would  not  be  satisfactory  where  real 
mission  stores  are  interf^ed  with. 

c.  All  validity  word  marking  was  achieved  by  preset  values  in  message  building 
software.  No  intelligence,  for  targeting  data,  was  built  into  validity  word  processing. 
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6.1.33  Header  Code  Management  [11.1.10.7] 

ISSUE:  What  AIS  design  should  be  employed  in  software  management  of  Header  Codes? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  The  main  header  code  used  in  the  AVS  was  the  safety  critical  control 
message  header  code.  Safety  critical  control  messages  were  assembled  in  different  parts  of  the 
software  (for  example  in  the  case  of  critical  control  words,  the  PCE  SMS  Level  4  package  STATE 
assembled  the  message;  for  system  time  updates,  the  PCE  SMS  Level  4  package 
SYSTEM_TIME_MANAGEMENT  assembled  the  message).  In  these  cases  the  header  code  was  placed 
into  the  first  word  of  the  message  by  accessing  a  comnton  constant  integer  equal  to  the  header  code 
value.  This  was  held  as  the  constant  integer  PCE  SMS  Level  4  package 
■CRITICAL_CONTROL_MESSAGE.  HEADEfi_WORD.“  This  has  the  advantage  of  containing  the 
header  code  to  one  point  in  the  application  code. 

6.1.34  Standard  Data  Word  Benefits  (11.1.11.1] 

ISSUE:  Can  the  benefits  of  standard  data  formats  be  realized  in  a  AIS  software  implementation? 

RATIONALE:  The  rationale  was  provided  In  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  The  AVS  PCE  included  an  entity  data  base  design  to  hold  all  available  data 
entity  codes.  It  was  refreshed  by  the  avionics  data  for  aircraft  .>ystem  data  entities  and  by  the 
S-4S  processor  store  sourced  data  entities.  Its  access  mechanism  was  ’fast  as  possible’  which 
resulted  in  its  data  structure  design  being  simplistic.  The  combining  of  the  entity  data  base  with 
the  standard  message  processing,  using  the  uf^aded  store  description,  proved  to  be  a  powerful 
software  design  solution. 

6.1.35  Base  Message  Usage  [11.1.12.1] 

ISSUE:  How  should  the  AIS  software  use  base  message  formats? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  The  base  message  format  was  embodied  into  each  message  building  routine. 
The  header  codes  were  availaWe  from  a  common  point  (see  1 1.1.10  of  Appendix  A),  and  validity 
words  were  packed  as  constants  for  each  message  transaction. 

6.1.36  Generic  Software  Development  [11.1.13.1] 

ISSUE:  Should  a  generic  mas'.:  data  transfer  set  of  software  be  developed  in  the  AIS  or  sfK}uld 
implementation  be  specific  to  each  mission  store? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

AVS  Implementation:  Mass  data  transfer  protocols  were  not  included  in  the  NOTICE  1  LDD  and 
therefore  not  implemented  by  the  AVS. 
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6.2  General  Software  Issues  This  section  provides,  where  applicable.  ..dditkinal  'afionale  and 
details  of  the  AVS  implementation  for  the  issues  raised  in  sectton  1 1 .2  of  Appendix  A. 

6.2.1  Lanouane  Selection  [11.2.1] 

ISSUE:  Which  software  language(s)  should  be  used  n  the  AIS? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance. 

AVS  Implementation:  Whenever  possftile  the  AVS  PCE  arid  SNE  software  were  written  in  Ada.  All 
other  processor  (SSE  8751,  PCE  BC  68000,  CSE  68000)  firmware  was  written  in  Assembler. 
The  elements  of  the  PCE  that  could  not  be  written  in  Ada  were: 

a  Interfacing  with  hardware  which  had  strict  short  timing  constraints  (such  as  PCE  RT 
hardware) 

b.  Bit  Manipulation 

c.  Semaphore  Access 

These  software  elements  formed  less  than  3  percent  of  the  overall  PCE  software  size  (some 
17,000  lines  of  source  code).  The  AVS  firmware  met  the  requirements  defining  firmware  as 
specified  in  MIL  STD-2167. 

6.2.2  Effects  of  Package  Structure  [11.2.2.1.1] 

ISSUE:  The  effect  of  the  Ada  package  structure  upon  the  design  of  AIS  software. 

RATIONALE:  The  rationale  was  provided  in  the  Appendbt  A  guidance. 

AVS  Implementation:  Throughout  the  PCE  avionic  processor  and  SMS  processor  software  design, 
the  Ada  package  has  been  exploited  to  bring  logically  related  functions  logether  and  to  provide 
structure  and  readability.  Within  the  SMS  processor,  the  design  solution  has  resulted  in  a  'lever 
approach  to  packages.  This  method  provide  an  excellent  structural  split  and  allowed  control 
over  the  design  package  dependencies  crucial  lor  a  good  Ada  design  solution.  The  following  list  of 
package  names,  extracted  from  the  PCE  SMS  processor  Ada  design  solution,  convey  the 
importance  of  the  package  to  the  AIS  design: 


a 

INITIAL  SEQUENCE 

) 

b. 

STORE  CONTROL 

) 

c. 

Ml  760  STORE  CONTROL 

)  from  Level  5 

d. 

AMRAAM  OONfi%)L 

) 

e. 

A»49L_CONTROL 

) 

f. 

POWER 

) 

a 

STATE 

) 

h. 

DISCRETE 

)  from  Level  4 

i. 

AUTHORTTY 

) 

j- 

SNE_C0NTR0L 

) 

k. 

ACYCLIC 

) 

I. 

CYCUC  MANAGER 

) 

m. 

MODE  CODE 

)  from  Level  3 

n. 

MESSAGE  FAILURE 

) 
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As  c»i  be  seen  just  by  package  name.,  logics^  groupings  of  system  software  raquirenfients  have 
occurred.  Each  of  the  above  packages  contains  procedures  and  functions  in  their  package 
specifications.  An  example  is  shown  in  figure  6.1.  which  is  an  extract  from  the  package 
STORe_OONTROL 


Package  Store.Control  Is 

Store_hur>g  raxceptlon 

I 

type  Poss_Jet_Types  is  (Eject,  PS,  Jet); 

subtype  Fu2ing_modes  is  AV_to_SMS_Comms.Mode_option_types 

range  Nose_fuze  . .  Nos6_and_t^_Fuze; 

subtype  SRAAM_modes  is  AVjo_SMS_Comms.Mode_o*«ion_iypes  range  boresight .  Slave: 

Last_fuzing  :Fu2ingLModes: 


LAst_SRAAM_Selected_Mode 

AMRAAM_3eiected_Missiie 

Selected_Missile 

Procedure  Hang_store  (Number 

Reason 


SRAAM_Modes; 

•AMRAAM_Control.Mode_Types; 

:Store_Numbers; 

:ln  store_numbers; 

tin  Store.Possible_hang_Reasons); 


Procedure  Change_Bomb_Fuzing(oew_Fuzing 

Achieved 

Procedure  Change.State  (Number 

New_state 

Procedure  Trigger_Store  (Num 

Procedure  Jettison_Store  (Num 

JeL't'  ypa 

Procedure  Select_storeJO'^_release 

(Class 

Selected_Quantity 


:Fuzing_modes; 
tout  Boolean); 

tin  Store.Numbers; 

tin  MIL_STD_1760.Demanded_Stales); 

tin  Store_Numbers); 

tin  Store_Numbers; 
tin  Poss_Jet_Types): 


tin  Slore.Ciasses; 

Jn  AV_to_SMS_CJomms.Weapons_packet; 
tin  Boolean; 
tout  Boolean); 


Page_Changed 
No  _Stores_of_requested_type 


Procedure  Deselect_Last_Store; 
Procedure  Reject_Selected  .Stores; 
end  Store  Control; _ _ 


FIGURE  6.1  Store  Control  Package  SpeciTication 
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6.2.3  Package  Devetopmeni  tof  Data  Only  [11.2.2.1.3] 

ISSUE:  Development  of  packages  containing  only  data. 

RATIONALE:  Tbe  ration^  was  provided  in  the  AppencSx  A  guidance. 

AVS  Implementation:  The  AVS  did  use  data  only  packages  aH  below  the  size  criteria  offered  in  the 
guidance.  These  packages  were  for  kiter  processor  communication  for  requests,  controls,  data 
entities  and  inventory.  As  long  as  the  size  of  these  packages  are  controled  and  the  specification 
contents  are  consistent  with  the  logical  grouping  goals  of  packages,  the  technique  works  weH  for 
inter  'activity'  communication. 

6-2.4  Ada  Tasking  (1 1 .2.2.21 

ISSUE:  Should  taskirrg  be  used  in  the  AIS  software  Design? 

RATIONALE:  The  rationale  was  piovided  in  the  Appendbt  A  guidance. 

AVS  Implementation:  Ada  Tasking  was  not  used  in  the  PCE  or  SNE  Ada  design  sokitiorts.  This  was 
because  the  task  switching  times  were  unacceptable  for  the  low  level  use  ot  tasks.  It  was  also  felt 
that  the  use  of  tasks,  even  for  high  level  state  control,  was  too  risky  for  the  program.  This  was 
because  of  the  immaturity  of  the  compiler  artd  its  un^rtying  multitasking  executive. 

6.2.5  Dynamic  Data  Structures  [11.2.2.3] 

ISSUE:  Should  dynamic  data  structures  be  used  within  an  AIS  design? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance. 

AVS  Implementation:  Early  experience  of  using  such  constructs  as  variant  records,  showed  that 
the  first  generation  Telesoft  Ada  compiler  dkf  not  manage  the  heap  very  wed.  It  was  a  risk 
reduction  decision  not  to  use  a^  dynamic  data  structures  within  the  AVS  Ada,  even  though  some 
requirements  (such  as  dynamic  configuration  and  extracted  store  descriptions)  lend  themselves 
well  to  these  Ada  constructs  (Access  types,  etc.). 

6.2.6  Exceptions  [11.2.2.4] 

ISSUE:  How  should  exceptions  be  used  in  an  AIS  software  design? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance. 

AVS  Implementation:  The  AVS  PCE  SMS  processor  Ada  desist  solution  makes  use  of  Ada  exceptions 
within  the  layered  approach  to  software  design.  Real  exceptional  events,  such  as  a  RT  on  the 
MIL>STD-1760  data  bus  has  ftiled,  are  communicated  via  package  specification  declared 
exceptions.  These  exceptions  travel  upwards  and  are  translated  at  eadi  level  into  more  system 
failures.  For  example  the  faikire  of  m  RT  oouto  be: 

a.  Levels  RT_Oead 

b.  Level  4  Mission_store_dead 

c.  Level  5  Hung_Storo 

The  AVS  experience  shows  that  timiting  exceptions  to  package  specifications,  promotes  good  use 
of  exceptions  resulting  in  a  better  software  standard. 
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62.7  Genetic  Units  [11.2.2.5] 

ISSUE:  When  should  genetic  units  be  est^ished? 

RATIONALE:  The  rational  was  provided  in  the  Appendix  A  guidance. 

AVS  Imptomentation:  The  PCE  Ada  software  did  not  have  any  generic  packages.  This  was  because 
the  compiler  did  not  implement  this  construct  and  that  even  H  it  did.  it  was  outside  the  scope  (rf 
the  contract  to  design  truly  generic  packages. 

52.8  Data  Hiding  [11.2.2.6] 

ISSUE:  How  should  date  hidirtg  be  used  in  AIS  software  design? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidartce. 

AVS  Implementation:  The  AVS  PCE  software  design  as  discussed  in  paragraph  1 122.1 3  of 
Appendix  A,  uses  the  package  program  unit  to  provide  the  logical  structure.  Wherever  posstole, 
data  structures  have  been  hidden  within  the  body  of  package.  The  PCE  SMS  processor  level  4 
package  STORE_DESCRIPT)ONS  is  a  good  example.  The  data  structure  holding  the  upload 
subaddress  implementation  is  hidden  from  the  calling  software  and  can  only  be  accessed  by 
dedicated  procedures  available  in  the  package  specification.  The  AVS  PCE  software  design  <Sti  not 
make  much  use  of  the  'Private  type'  construct.  This  was  mainly  due  to  the  inexperience  of  tSte 
software  design  team  in  using  Ada. 

6.2.9  Separate  Compilation  [11.2.2.7] 

ISSUE;  Use  of  the  separate  compilation  Ada  feature  to  assist  in  program  modulization. 

RATIONALE:  The  rationale  was  provided  in  Mie  Appendbt  A  guidance. 

AVS  Implementation:  This  Ada  feature  was  not  available  in  the  first  generation  Telesoft  Ada 
compiler. 

62.10  Constraint  Checking  (11.2.2.8} 

ISSUE:  When  should  full  constraint  checking  be  applied  to  object  code? 

RATIONALE:  The  rationale  was  provided  in  the  Appendbc  A  guidance. 

AVS  Implementation:  During  the  devetojwient  of  the  AVS  Ada  software,  a#  constraint  checking 
was  switched  on.  Additionally,  the  design  of  the  software  ensured  that  all  variables  were 
constrained  to  the  relevant  range.  Subtypes  of  integer,  for  example,  were  used.  During  testing 
this  feature  proved  mvakiable.  This  was  mainly  due  to  the  co-resident  RTS  srrftware  trappktg  a 
run  time  constraint  error  and  then  printing  a  diagnostic  message  providing  the  tore  nurnber  of 
the  package,  thus  indtcatiirg  where  the  wn  time  assignment  was  out  of  itmge.  The  final  deSvery 
had  construct  (rftecking  switched  off.  using  a  language  pragmatism,  which  rechrced  the  final  object 
size  by  about  30  percent. 

6.2.11  Attributes  [11.22.9] 

ISSUE:  Should  attrixites  be  used  m  AIS  software? 
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RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance. 

AVS  Implementation;  Wherever  possible  a  data  attribute  was  used.  This  meant  '.hat  type  and 
subtypes  oouM  be  changed  without  the  need  to  change  the  application  code.  The  AVS  therefore 
proved  that  this  was  a  very  cost  effective  construct. 

6.2.12  Data  Abstraction  [11.2.2.10] 

ISSUE:  How  should  data  abstraction  techniques  be  applied  to  AIS  software  design 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance. 

AVS  Implementation:  The  development  of  data  structures  to  provide  the  main  control  routes 
within  the  Ada  code  was  important  to  the  AVS  software  design  selection.  A  good  example  of  the 
abstraction  of  the  requirement  into  suitable  data  structures  is  the  PCE  SMS  processor  Level  4 
package  CRITICAL_CONTROL_MESSAGE  where  enumeration  types,  records  and  arrays  are  all  used 
together  to  describe  all  subaddress  1 1  interface  stales  for  a  particular  pylon  station.  The  AVS 
experience  shows  that  careful  design  of  data  structures  can  result  in  more  readable  and 
understandable  code. 

6.2.13  Portability  [11.2.2.11] 

ISSUE;  How  can  AIS  software  be  ported  to  diherent  targets? 

RATIONALE;  The  rationale  was  provided  in  the  Appendix  A  guidance. 

AVS  Implementation:  The  AVS  Ada  processor  reduced  assembler  inserts  to  a  minimum.  They 
were  used  for: 

a  Past  hardware  access  (see  Avionics  RT  access) 

b.  Bit  manipulation  (package  BIT_FUNCTIONS) 

c.  Semaphore  (package  SEMAPHORE) 

d.  Some  interrupt  handling  (see  Avionics  Processor) 

In  terms  of  overall  percentage  of  target  object  code,  these  inserts  were  reduced  to  some  three 
percent.  The  AVS  implementation  is  therefore  very  portable. 

6.2.14  Instruction  Set  Architectures  [11.2.3] 

ISSUE:  Whicn  computer  Instruction  Set  Architectures  (ISA)  should  be  used  in  the  AIS. 
RATIONALE;  The  rationale  was  provided  in  the  Appendix  A  guidance. 

AVS  Implementation:  The  AVS  used  the  Motorola  68000  ISA  for  the  main  controlling  units.  This 
ISA  proved  to  be  well  suited  to  the  requirements  of  a  modem  avionics  system  using  Ada. 

6.2.15  Processing  Power  [11.2.4.1] 

ISSUE:  What  typical  processing  power  trends  occur  from  implanting  the  LDD  following  the 
guidance  in  Section  11.1? 

RATIONALE;  The  rationale  was  provided  in  the  Appendix  A  guidance. 
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6.2.16  Code  Memory  (11.2.4.2.1) 

ISSUE;  How  much  exira  code  memory  is  rea  ed  in  the  AIS? 

RATIONALE;  The  benefits  in  terms  of  software  size  reduction,  and  therefore  code  memory 
reduction,  resulting  from  the  implementation  nf  generic  software  will  only  be  realized  in 
systems  using  more  than  one  MIL  STD-1760  store  type.  This  is  because  generic  software  has 
an  overhead  and  by  its  very  nature  it  cannot  be  optimized  to  specific  stores.  The  more  store 
types  used,  the  more  software  size  benefits  occur  through  the  use  of  generic  software. 

AVS  Implementation;  All  MIL-STO-1760  emulated  mission  stores  (SRAAM,  AGM,  and  BOMB) 
are  controlled  by  one  common  control  package  (PCE  SMS  processor  Level  4  package 
M1760_Store_Control)  which  calls  generic  software  for  message  processing  and  safety  critical 
store  control.  An  overhead  would  be  incurred  if  this  scheme  was  used  for  a  single  store  type,  but 
combining  all  control  for  multiple  store  types  in  one  package,  yields  software  size,  and  therefore 
code  merr.ory  size  reductions. 

6.2.17  Data  Memory  (11.2.4.2.2) 

ISSUE;  How  much  data  memory  is  required  for  an  AIS  software  design? 

RATIONALE;  It  is  not  possible  to  provide  absolute  figures  for  the  extra  data  memory 
requirements  as  it  is  very  application  dependent.  However,  the  figure  provided  is  likely  based 
upon  the  size  of  data  allocated  in  AVS. 

AVS  i.nr  ^mentation;  AVS  allocated  one  data  word  for  every  declared  data  entity  code.  It 
14  sd  the  store  description  data  structure  to  the  information  upload  and  held  bitlog 
•  orr.,.>‘  on  for  each  RT  and  therefore  each  mission  store. 

^.2.18  Software  Architectures  (11.2.5) 

ISSUE:  What  is  the  best  overall  software  structure  for  an  AIS  implementation? 

RATIONALE;  The  rationale  was  provided  in  the  Appendix  A  guidance. 

AVS  Implementation:  The  AVS  software  responsible  for  system  control  in  the  PCE  SMS  is 
structured  on  a  highly  layered  approach  wt  rh  is  consistent  with  the  guidance  offered.  Figure 
6.2  shows  the  AVS  FCE  SMS  packaoe  stru...  <*.  This  approach  proved  a  very  successful  way  of 
developing  AIS  software  offering  adv?'  '  ges  in  all  phases  of  the  software  life  cycle. 

6.2.19  Reusable  Software  [  .2.6] 

ISSUE:  How  can  reuseable  software  be  developed? 

RATIONALE:  Reuseability  in  software  is  only  realized  when  generic  software  is  developed.  This 
is  because  only  general  purpose  software  built  upon  a  standard  protocol  (such  as  the 
MIL-STD  1760  LDD)  can  be  taken  from  one  application  to  another.  Store  specific  software  is 
just  that.  It  tends  to  inie:ma«e  with  application  specific  software  and  therefore  cannot  cost 
effectively  be  re-csed. 

AVS  Implementation:  Miihough  the  Ada  generic  package  construct  was  not  available,  the  software 
was  designed  to  be  general  purpose  and  this  proved  that  reusable  software  could  be  developed  for 
many  elements  of  the  LDD. 
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6.2.20  Software  Interfaces  (11.2.7] 

ISSUE.  How  many  meaningful  software  interfaces  can  be  developed? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance. 

AVS  Implementation:  Close  inspection  of  the  final  PCE  Ada  code  shows  good  use  of  data  abstraction 
techniques  and  extensive  case  of  meaningful  names.  This  combination  results  in  both  readability 
and  understandability  that  is  built  into  the  source  code. 

6.2.21  Program  Support  Environment  (11.2.8) 

ISSUE:  Should  a  software  support  environment  be  used? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance. 

AVS  Implementation:  The  AVS  compiler,  chosen  since  it  was  the  only  available  VAX  hosted  and 
Motorola  68000  targeted  cross  compiler,  was  supplied  with  a  very  poor  toolset  ana  support 
environment.  The  software  testing  and  integration  suffered  from  this  lack  of  available  tools.  The 
missing  tools  which  had  the  most  impact  were:  the  Library  Manager,  Symbolic  Debugger,  and 
Good  Quality  Linker. 

6.2.21.1  Library  Manager  It  is  the  responsibility  of  a  Library  Manager  to  determine  all 
compilation  dependencies  and  initiate  automatic  recompilations  if  a  source  unit  is  changed  which 
effects  other  units.  This  was  not  available  during  AVS  Ada  development  and  meant  that  It  had  to  be 
done  manually.  This  was  both  time  consuming  and  resulted  in  errors.  The  overall  effect  was  a 
reduction  in  productivity  and  an  increase  in  maintenance  costs. 

6.2.21 .2  Symbolic  Debugger  This  facility  allows  tracing  of  Ada  constructs  which  is  achieved  by 
the  debugger  having  knowledge  of  the  relationship  between  target  code  and  the  source  code.  It 
speeds  up  testing  and  debugging. 

6.2.21 .3  Good  Quality  Linker  Such  a  Linker  would  supply  address  map  information  locating  Ada 
constructs  to  physical  addresses.  This  information  is  paramount  if  such  debugging  tools  as  Logic 
State  Analyzers  are  to  be  used.  The  lack  of  this  information  during  AVS  software  development 
significantly  extended  debugging  ’.imes. 

6.2.22  Software  Configuration  Control  (11.2.9) 

ISSUE:  What  type  of  Configuration  Control  environment  should  be  used  for  control  of  AIS 
software? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance. 

AVS  Implementation:  No  automated  configuration  control  tools  were  used  during  AVS  software 
development.  A  manual  system  was  developed  which  was  just  about  sufficient.  However,  for  it  to 
be  successful  it  relies  on  the  professionalism  of  the  software  engineer  to  follow  the  procedures. 
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7.  RATIONALE  FOR  APPENDIX  A  SECTION  12 


Paragraphs  7.1  through  7.6  of  this  section  provide  rationale  to  support  the  guidance  given  in 
paragraphs  12.1  through  12.3  of  Apperxjix  A. 

7.1  Connectors  (12.1] 

ISSUE:  What  specific  requirements  of  MIL-C-38999  should  be  reflected  into  other  pads  of  the 
AIS  not  controlled  by  MIL-STD-1760? 

RATIONALE:  It  is  most  likely  that  aircraft  manufacturers  will  use  the  solution  that,  in  the  shod 
term,  may  be  lowest  in  cost.  There  is  little  doubt  that  using  size  8  twinax  contacts 
(MIL-C-39029  slash  90  and  91)  will  be  more  expensive  than  using,  say,  three  size  22  power 
contacts  in  its  place.  Also,  the  increased  weight  penalty  incurred  by  utilizing  the  extra 
screening  potential  of  MIL-C-38999  Series  III  connectors  will  be  viewed  with  some  alarm. 
Nevedheless  it  is  considered  imperative  that: 

a  The  same  type  of  contacts  called  out  in  MIL-STD-1760  for  the  ASI  are  used 
throughout  the  rest  of  the  AIS.  This  will  afford  the  required  impedance  matching  (vital  for  HB1 
VSWR);  screening  (against  susceptibility  and  radiation  of  noise);  and  also  automatically  control 
the  cable  which  will  be  used,  because  the  contact  slash  sheets  detail  the  "acceptable’  cable. 

b.  MIL-C-38999  connectors  are  used  either  throughout  the  AIS  installation  or,  as  a 
minimum,  wherever  the  360  degree  screening  afforded  by  these  connectors  is  considered  to  be 
beneficial.  This  capability  is  obviously  going  to  have  significant  advantages  when  dealing  with 
composite  structures. 

7.2  MulliDlflx,Data  Bus  Cable  (12.2] 

ISSUE:  Should  specific  cable  be  used  in  the  AIS  installation? 

RATIONALE:  Should  the  advice  given  in  paragraph  7.1  above  be  ignored  and  MIL-C-39029  slash 
sheets  90  and  91  contacts  not  be  used,  then  cable  ’control”  will  be  lost.  There  are  other  costly 
types  of  cable  available  which  would  give  reasonable  electrical  compatibility,  but  are  usually  not 
approved  and  are  of  doubtful  mechanical  structure. 

7.3  High  Bandwidth,  Cable  [12  3] 

ISSUE:  Should  specific  cable  be  used  in  the  AIS  installation? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

7.4  Release  Consent  and  Interlock  Cables  (12.4) 

ISSUE:  No  applicability. 
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7.5  Kddffisa  Lina  Cabifl  |12.5] 
ISSUE:  No  applicability. 

7.6  Panfflf  Cablfl  112-6] 
ISSUE:  No  applicability. 


8.  RATIONALE  FOR  APPENDIX  A  SECTION  13 


Paragraphs  8.1  through  8.19  of  this  section  provide  rationale  to  support  the  guidance  given  in 
paragraphs  13.1.1  through  13.3  of  Appendix  A.  Issue  statements  may  be  summarized.  Where 
rationale  was  supplied  in  the  guidance  text  and  further  provision  considered  superfluous,  then 
extra  rationale  is  not  supplied. 

8.1  Connectors  {13.1.1] 

ISSUE:  Should  the  Mil  -STO-1760  connectors  be  fitted  on  the  first  available  opportunity? 

RATIONALE:  Delaying  the  fitting  of  the  ASI  connectors  will  be  of  little  or  no  benefit  and  in  fact 
could  cause  an  unnecessary  delay  in  any  future  modification  program.  It  is  very  obvious  that  a 
major  milestone  in  any  modification  program  is  that  area  connected  with  the  initial  fit,  or 
change,  of  any  hardware.  If  the  airaaft,  or  its  pylons,  is  ’opened  up'  for  modification,  then  that 
opportunity  should  be  utilized  to  complete  the  installation  of  MIL'STD'1760  ASI  connectors  ar>d 
any  associated  wiring,  the  latter  may  have  to  be  tied  back*  at  any  appropriate  LRU  interfaces. 

ISSUE:  Could  some,  or  all,  of  the  existing  connectors  be  superseded  by  the  MIL-STD-1760 
connector? 

RATIONALE:  There  are  two  major  reasons  for  considering  this  topic: 

a  Removing  the  current  connectors  from  the  aircraft/pylon  structure,  will  yield  real 
estate  which  could  be  vital  in  the  fitting  of  MIL*STD-1760  ASIs. 

b.  A  'standard*  umbilical  could  be  realized  in  a  much  shorter  timescale. 

There  are  two  major  problems  which  may  legislate  against  such  an  installation: 

a  The  logistics  of  having  post  mod  aircraft  without  post-mod  stores  or  post-mod  only 
stores  against  pre-mod  aircraft.  It  should  be  noted  that  although  special  to  type  umbilicals.  that 
is  MIL-STD-1760  ASI  compatible  at  one  end  and  store  specific  at  the  other,  may  go  some  way  in 
alleviating  this  problem,  it  would  be  a  very  expensive  solution  unless  easily  modifiable 
umbilicals  were  constructed. 

b.  Real  estate  would  need  to  be  found,  either  in  the  pylon  or  the  aircraft,  for  the  LRU 
which  is  to  control  the  switching  and  or  rerouting  of  these  existing  signals. 

In  spite  of  the  disadvantages  discussed  above  it  is  still  recommended  that  each  store/aircraft 
interface  be  studied  in  its  own  right  and  accepted  or  rejected  on  its  own  merits.  A  specific  policy 
can  then  be  established  for  each  aircraft  which  can  be  defended,  rather  than  have  a  blanket 
decision  which,  almost  certainly,  could  not. 

ISSUE:  Where  should  the  ASI  be  fitted. 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  .\  guidance  and  no  further  rationale  is 
necessary. 

3.2  Power  Installation  {13.1.2.1] 

ISSUE:  What  28V  DC  wire  will  already  be  fitted  and  useable? 


393 


RATIONALE:  The  rationale  \was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

ISSUE:  What  115V  AC  wire  will  already  be  fitted  and  usedbie? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

ISSUE:  What  initial  Auxiliary  power  capability  will  there  be? 

RATIONALE:  All  of  the  information  currently  available  indicates  that  the  auxiliary  power 
capability  is  unlikely  to  be  required.  Before  any  commitment  is  made  to  even  start  design,  never 
mind  installation,  of  the  auxiliary  power  signal  set,  that  is  a  Class  lA  or  HA  ASI,  the  justification 
for  the  requirement  must  be  fully  examined.  This  is  because  such  an  installation  will  require  a 
second  ASI  connector  and  associated  cable.  The  real  estate  required  for  such  an  installation  will 
be  a  heavy  burden  to  bear,  as  will  the  consequent  aircraft  weight  increase,  unless  adequate 
justification  is  provided. 

ISSUE:  Will  Auxiliary  Interlock  be  required  and  available? 

RATIONALE:  The  rationale  was  provided  i'i  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

8.3  Multiplex  Data  Bus  Installation  (13.1.2.2) 

ISSUE:  What  aircraft  are  likely  to  have  this  installation  already  in  place? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

ISSUE:  Should  this  be  a  classic  bus  layout? 

RATIONALE:  Refer  to  section  5  of  this  document  for  further  detailed  rationale  on  this  subject. 

8.4  Multiplex  Daia  Bus  Address  Installation  (i3.i.2.3] 

ISSUE:  What  aircraft  are  likely  to  have  this  installation  already  in  place? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

ISSUE:  What  part  of  the  aircraft  is  affected? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  atKl  rto  further  rationale  is 
necessary. 

8.5  Low  Bandwidth  Installation  (13.1.2.4] 

ISSUE:  What  aircraft  are  likely  to  have  this  installation  already  in  place? 

RATIONALE:  Tlw  contact  and  therefore  c{d))e,  provided  in  MIL-STD‘1760  for  thte  signal,  is  a 
F^n  surrounded  (360')  by  two  rings.  It  is  intended  that  the  active  signal  (HI)  be  carried  on  the 
pin,  with  tfie  return  (LO)  being  carried  on  the  first  ring.  Thte  leaves  the  second  outer  ring  for  a 
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screen  and  attogelher  this  provides  for  a  twisted  pair  with  overall  screen  cable,  that  is  the  same 
contact  as  required  for  the  Multiplex  Data  Bus.  Currently  such  a  facility  is  typically  used  for 
the  rather  raw  target  acquired  audio  signal  from  the  AIM-9  missile,  but  fed  to  the  aircraft  via  a 
single  wire  with  an  overall  grounded  screen,  that  is  HI  via  the  wire  and  LO  via  the  screen. 

While  little  change  of  usage  is  envisaged  in  the  short  term,  there  are  long  term  considerations 
for  using  this  interface  for  Low  Speed  Digital  Signals  (LSDS)  with  low  cost  (electronics)  stores. 
The  current  installations  discussed  above  would  be  totally  inadequate  for  use  with  the  LSDS, 
whereas  the  installation  required  by  MIL-STD-1760  would  be  more  than  adequate  for  both  the 
LSDS  and  AIM-9  audio.  Note  that  the  AIM-9  audio  installation  is  a  point  to  point  requirement  and 
this  is  also  the  type  of  installation  envisaged  for  the  LSDS,  thereby  avoiding  the  requirement  for 
bus  network  address  lines. 

8.6  High  Bandwidth  Installation  (13.1.2.5| 

ISSUE:  Will  existing  cable  be  suitable? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

8.7  Interlock  Line  Installation  (13.1.2.6) 

ISSUE:  Is  Interlock  a  positive  requirement? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

ISSUE:  Must  the  Interlock  Return  be  isolated. 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

8.8  Release  Consent  Installation  (13.1.2.7) 

ISSUE:  Are  straight  installation  rules  specified  for  this  signal? 

RATIONALE:  Unfortunately  many  people  distrust  the  use  of  digital  data  for  the  transmission  of 
safety  critical  commands  and  this  actually  includes  the  generation  of  such  commands  by  the 
processor.  Furthermore,  although  it  can  be  shown  that  the  risk  of  the  false  generation  of  a  safety 
aitical  message  (which  will  pass  all  checking  and  therefore  be  acted  upon)  is  very  low,  such 
figures  as  these  seem  to  be  beyond  comprehension  and  are  consequently  also  completely 
mistrusted.  In  order  that  the  flexibility  of  digital  data  can  be  retained,  but  that  it  becomes 
‘safety  related*  not  ‘safety  critical,*  the  use  of  a  discrete  (which  must  accompany  such  data)  has 
been  mandated.  That  discrete,  now  a  nominal  2BV  DC  line  capable  of  a  current  drain  up  to  100 
milliamperes,  is  called  Release  Consent  and  is  mandated  for  use  whenever  bits  D8  anchor  DIO  of 
the  Critical  Control  1  word  (MIL-STD-1760A  Table  B.XXXII)  are  set  to  Logic  1.  Use  at  other 
times  is  at  the  discretion  of  the  store,  but  the  aircraft  must  be  capable  of  complying  with  such  a 
demand.  It  is  this  rationale  which  has  led  to  the  guidance  that  Release  Consent  should  not  to  be 
software  generated  (where  this  includes  the  use  of  a  data  highway  for  transmission  of  any 
generation),  but  may  be  software  steered  (where  this  includes  the  use  of  a  data  highway  for 
transmission  of  steering  instructions),  such  as  in  a  multi  (rail  launch)  store  carriage  store. 


8.9  Bus  ConlrQller  (13.1.3.1) 

ISSUE:  Should  a  separate  MIL-STD-1760  bus  be  installed? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

8.10  Avionic  to  SMS  Digital  Interface  (13.1.3.2) 

ISSUE:  How  should  "Avionics  Data*  be  transferred  into  stores? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

8.11  Digital  Control  (13.1.3.3) 

ISSUES:  What  sort  of  aircraft  nKxlirications  are  required  on  partially  digital  AIS  or  SMS  and 
aircraft  which  have  as  yet,  no  digital  AIS  or  SMS? 

RATIONALE:  It  is  most  unlikely  that  a  single  processor  will  be  able  to  cope  with  the  duties  of  a 
Bus  Controller.  Stores  Management  System  Manger  and  be  responsible  for  the  processing 
requirements  of  assembling  the  data  entity  words  into  the  correct  order  (this  assumes  that  the 
data  entity  arrived  from  the  Avionics  Bus  using  MIL-HDBK-1553  message  and  data  word 
formats)  for  the  various  weapon  on  any  one  mission.  It  is.  however,  expected  that  two 
processors  could  cope  quite  adequately  and  this  then  leaves  the  question  of  partitioning  the 
'duties*  described  above.  Obviously  software  partitioning  of  safety  critical  and  non-safety 
critical  functions  form  a  basic  requirement  on  any  decision,  which  means  that  the  partitioning 
falls  into: 

a  Processor  1  •  SMS  Management 

b.  Processor  2  •  Bus  Controller  and  message  construction 

8.12  Bandwidth  Switching  (13.1.3.4) 

ISSUE:  What  bandwidth  switching  is  likely  to  be  available  on  current  aircraft? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

8.13  Rgyyef  ConlfOl  (13-1.3.5) 

ISSUE:  Do  28V  DC  Power  1  and  28V  DC  Power  2  channels  require  separate  control? 

RATIONALE:  Because  28V  DC  2  is  the  supply  determined,  by  MIL-STD-1760,  for  use  on  DC 
controlled  safety  critical  store  functions,  then  the  time  for  which  it  will  be  available  to  any 
store(s)  is  likely  to  be  very  small  and  rightly  so.  This  is  not  the  case  for  28V  DC  1 ,  which  is  a 
general  purpose  supply  and  this  factor  alone  dictates  a  separated  switching  policy. 

ISSUE:  Why  and  when  does  the  1 15V  AC  channel  ret^ire  deadfacing? 

RATIONALE:  The  rationale  was  provided  in  the  Apperxlix  A  guidance  and  no  further  rationaie  is 
necessary. 
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ISSUE;  Is  power  capacity  likely  to  be  adequate? 

RATIONALE:  MIL-STO*1760  only  demands  a  specific  citoacity  at  any  one  ASI,  which  is: 

a  28V  DC  -  20  amperes  to  be  available  for  Class  I  and  II;  and  30  anrperes  to  be 
available  for  Class  lA  and  HA. 

b.  115V  AC  - 10  amperes  per  phase  to  be  available  for  Class  I  ar>d  II;  and  30  amperes 
per  phase  to  be  available  for  Class  lA  and  HA. 

Note:  The  30  ampere  figure  is  the  maximum  consumable  across  both  primary  and  auxibary 
signal  sets  together. 

The  capacity  requirements  for  how  many  ASIs  should  be  energized  at  any  one  time,  is  not 
controlled  by  MIL-STC>>1760,  because  this  is  obviously  aircrah  type  dependent  arxl  also 
probably  varies  across  build  block  of  any  one  type.  The  capadfy  requirement  for  switching  is 
lately  to  need  expansion  in  order  to  cope  with  the  28V  DC  1  and  28V  DC  2  separation  and 
also  the  "deadfacing*  requirements  levied  against  the  115V  AC. 

8.14  Interlock/Release  Consent  Cireuitrv  (13.1.3.6) 

ISSUE:  Should  Interlock  interrogation  be  implemented? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

ISSUE:  Should  Interlock  be  used  for  deadfadng  power  to  the  connector? 

RATIONALE:  For  the  1 1SV  AC  power  supply,  the  current  practice  of  deadfadng  via  the  interlock 
must  cease  in  order  to  be  compliant  wiih  MIL  STD-1760.  The  same  technical  reasoning  cannot 
be  applied  to  the  DC  power  lines,  although  it  most  certainly  will,  if  the  270V  DC  power  line  is 
ever  implemented,  but  it  is  considered  to  be  bad  engineering  practice  to  disconnect  ’hoT 
connectors  and  even  worse  practice  to  connect  'hot*  connectors,  in  the  latter  case,  unless  the 
mating  is  t00%  clean,  current  spiking  will  occur  on  both  the  interlock  line  (this  will  almost 
certainly  be  highly  inductive)  and  the  28V  DC  1  line. 

ISSUE:  What  circuitry  is  required  for  Interlock? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationale  is 
necessary. 

ISSUE:  What  drcuitry  is  required  for  Release  Consent? 

RATIONALE:  See  paragraph  8.8  of  this  documenL  in  association  with  the  rationale  in  13.1.2.7. 

8.15  Avionic  Interface  (13.1.4) 

ISSUE:  What  avionic  data  does  MIL-STO-1760  demand  from  the  aircraft? 

RATIONALE:  The  rationale  was  provided  In  the  Apperxfix  A  guidartce  and  no  further  ratioftde  is 
necessary. 
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8.16  Positive  Testing  [13.2.1.] 


ISSUE:  What  part(s)  of  the  MIL-STt)-l760  installation  should  be  carxlidates  for  positive 
testing? 

RATIONALE:  Basically  one  needs  to  look  at  those  pans  of  the  system  which  wfl  require  sy^em 
integration,  that  is  where  different  equipment  have  to  live  mutually  with  and  without  each  other. 
This  is  obviously  a  main  criteria  for  bus  nehvorking  and  that  is  why  the  three  that  appear  in 
Appendix  A  were  chosen.  The  power  lines  were  included  as  a  possfote  extra  only  for 
consideration  against  potential  voltage  drop  on  larger  aircraft,  that  is  testing  to  ensure  that  the 
correct  wire  gauge  was  chosen  by  the  designer. 

8.17  Verification  bv  Inspection  [13.2.1.2] 

ISSUE:  What  pan(s)  of  the  MIL-STD-1760  installation  could  be  considered  for  design 
verification? 

RATIONALE:  See  paragraph  8.t6  of  this  document,  in  association  with  the  rationale  in  13.2.1.1. 

8.18  EMC  [13.2.1.3] 

ISSUE:  What  EMC  testing,  if  any,  should  be  considered? 

RATIONALE:  See  paragraph  7.1  of  this  document,  especially  that  part  on  cost  cutting,  in 
association  with  the  rationale  in  [13.2.1.3).  that  is  the  less  active  screening  fitted  in  the 
installation  the  more  irrportant  be^mes  the  depth  of  EMC  testing. 

8.19  Phased  MIL-STD-1760  Implementation  [13.1] 

ISSUE:  What  part  of  the  installation  should  be  implemented  first? 

RATIONALE:  The  rationale  was  provided  in  the  Appendix  A  guidance  and  no  further  rationaie  is 
necessary. 
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